streamalism.org

1. Uvod

U ovom uputstvu naučit ćemo o tome obrazac dizajna Service Locator na Javi.

Opisat ćemo koncept, primijeniti primjer i istaknuti prednosti i nedostatke njegove upotrebe.

2. Razumijevanje obrasca

Svrha obrasca Locator Service je vraćanje instanci usluga na zahtjev. Ovo je korisno za odvajanje potrošača usluga od klasa betona.

Provedba će se sastojati od sljedećih komponenata:

• Klijent - objekt klijenta je potrošač usluge. Odgovorna je za pozivanje zahtjeva iz pretraživača usluga

• Locator Service - komunikacijska je ulazna točka za vraćanje usluga iz predmemorije

• Predmemorija - objekt za pohranu referenci na uslugu kako bi se kasnije ponovno upotrijebili

• Inicijalizator - stvara i registrira reference na usluge u predmemoriji

• Usluga - komponenta Usluga predstavlja izvorne usluge ili njihovu implementaciju

Izvorni objekt usluge traži lokator i vraća ga na zahtjev.

3. Provedba

Ajmo sada postati praktični i pogledati koncepte kroz primjer.

Prvo ćemo stvoriti MessagingService sučelje za slanje poruka na različite načine:

javno sučelje MessagingService {String getMessageBody (); Niz getServiceName (); }

Dalje ćemo definirati dvije implementacije sučelja koje šalju poruke e-poštom i SMS-om:

javna klasa EmailService implementira MessagingService {public String getMessageBody () {return "poruka e-pošte"; } javni String getServiceName () {return "EmailService"; }}

The SMSService definicija razreda slična je EmailService razred.

Nakon definiranja dviju usluga, moramo definirati logiku njihove inicijalizacije:

javna klasa InitialContext {traženje javnog objekta (niz ime usluge) {if (serviceName.equalsIgnoreCase ("EmailService")) {return new EmailService (); } else if (serviceName.equalsIgnoreCase ("SMSService")) {return new SMSService (); } return null; }}

Posljednja komponenta koja nam treba prije spajanja objekta lokatora usluge je predmemorija.

U našem primjeru ovo je jednostavna klasa s a Popis svojstvo:

predmemorija javne klase {usluge privatnog popisa = novi ArrayList (); javna MessagingService getService (StringnameName) {// dohvaćanje s popisa} javna praznina addService (MessagingService newService) {// dodavanje na popis}} 

Napokon, možemo implementirati našu klasu lokatora usluga:

javna klasa ServiceLocator {private static Cache cache = new Cache (); javna statička MessagingService getService (StringnameName) {MessagingService service = cache.getService (serviceName); if (usluga! = null) {povratna usluga; } Kontekst InitialContext = novi InitialContext (); MessagingService service1 = (MessagingService) context .lookup (serviceName); cache.addService (usluga1); usluga povrata1; }}

Logika je ovdje prilično jednostavna.

Klasa sadrži primjerak Predmemorija. Zatim, u getService () metoda, prvo će provjeriti predmemoriju za primjerak usluge.

Onda, ako je to null, pozvat će inicijalizacijsku logiku i dodati novi objekt u predmemoriju.

4. Ispitivanje

Pogledajmo kako sada možemo dobiti instance:

MessagingService service = ServiceLocator.getService ("EmailService"); Niz e-pošte = service.getMessageBody (); MessagingService smsService = ServiceLocator.getService ("SMSService"); Niz sms = smsService.getMessageBody (); MessagingService emailService = ServiceLocator.getService ("EmailService"); Niz newEmail = emailService.getMessageBody ();

Prvi put kad dobijemo EmailService od ServiceLocator kreira se i vraća nova instanca. Zatim, nakon što ga sljedeći put pozovete EmailService bit će vraćen iz predmemorije.

5. Locator usluge vs ubrizgavanje ovisnosti

Na prvi pogled obrazac Service Locator može izgledati slično drugom dobro poznatom uzorku - naime, ubrizgavanju ovisnosti.

Prvo, važno je to napomenuti i ubrizgavanje ovisnosti i obrazac lokatora usluga implementacije su koncepta inverzije upravljanja.

Prije nego što nastavite dalje, u ovom tekstu saznajte više o ubrizgavanju ovisnosti.

Ključna razlika ovdje je u tome što objekt klijenta i dalje stvara svoje ovisnosti. Za to samo koristi lokator, što znači da mu je potrebna referenca na objekt lokatora.

Za usporedbu, kada se koristi injekcija ovisnosti, klasi se daju ovisnosti. Injektor se poziva samo jednom prilikom pokretanja radi ubrizgavanja ovisnosti u klasu.

Na kraju, razmotrimo nekoliko razloga za izbjegavanje upotrebe obrasca Locator Service.

Jedan od argumenata protiv toga je da otežava jedinično testiranje. Uz ubrizgavanje ovisnosti možemo testiranu instancu proslijediti lažne objekte ovisne klase. S druge strane, ovo je usko grlo s uzorkom Service Locator.

Drugo je pitanje što je složenije koristiti API-je na temelju ovog uzorka. Razlog tome je što su ovisnosti skrivene unutar klase i provjeravaju se samo tijekom izvođenja.

Unatoč svemu tome, obrazac Service Locator lako je kodirati i razumjeti, a može biti izvrstan izbor za male aplikacije.

6. Zaključak

Ovaj vodič pokazuje kako i zašto koristiti obrazac dizajna Service Locator. Raspravlja o ključnim razlikama između uzorka dizajna Service Locator-a i koncepta ubrizgavanja ovisnosti.

Općenito je na programeru da odabere kako će dizajnirati klase u aplikaciji.

Uzorak lokatora usluga jednostavan je obrazac za razdvajanje koda. Međutim, u slučaju korištenja klasa u više aplikacija, ubrizgavanje ovisnosti pravi je izbor.

Kao i obično, cjeloviti kôd dostupan je u projektu Github.