streamalism.org

1. Úvod

V tomto výučbe sa dozvieme niečo o návrhový vzor vyhľadávača služieb v Jave.

Popíšeme tento koncept, implementujeme príklad a zdôrazníme výhody a nevýhody jeho použitia.

2. Porozumenie vzoru

Účelom vzoru vyhľadávača služieb je vrátiť inštancie služby na požiadanie. To je užitočné na oddelenie spotrebiteľov služieb od konkrétnych tried.

Implementácia bude pozostávať z týchto komponentov:

• Klient - objekt klienta je spotrebiteľ služby. Zodpovedá za vyvolanie požiadavky z vyhľadávača služieb

• Service Locator - je vstupný bod komunikácie pre vrátenie služieb z medzipamäte

• Vyrovnávacia pamäť - objekt na ukladanie referencií na služby, aby ste ich mohli neskôr znova použiť

• Initializer - vytvára a registruje odkazy na služby v cache

• Služba - komponent Služba predstavuje pôvodné služby alebo ich implementáciu

Pôvodný objekt služby vyhľadá lokátor a vráti sa na požiadanie.

3. Implementácia

Poďme teraz do praktického rozsahu a pozrime sa na koncepty na príklade.

Najskôr vytvoríme a MessagingService rozhranie pre posielanie správ rôznymi spôsobmi:

verejné rozhranie MessagingService {String getMessageBody (); Reťazec getServiceName (); }

Ďalej definujeme dve implementácie rozhrania vyššie, ktoré odosielajú správy prostredníctvom e-mailu a SMS:

verejná trieda EmailService implementuje MessagingService {verejný reťazec getMessageBody () {návrat "e-mailová správa"; } public String getServiceName () {return "EmailService"; }}

The SMSService definícia triedy je podobná definícii triedy EmailService trieda.

Po definovaní týchto dvoch služieb musíme definovať logiku ich inicializácie:

public class InitialContext {public Object lookup (String serviceName) {if (serviceName.equalsIgnoreCase ("EmailService")) {return new EmailService (); } else if (serviceName.equalsIgnoreCase ("SMSService")) {vrátiť nový SMSService (); } return null; }}

Posledným komponentom, ktorý potrebujeme pred zostavením objektu vyhľadávača služieb, je vyrovnávacia pamäť.

V našom príklade je to jednoduchá trieda s a Zoznam nehnuteľnosť:

verejná trieda Cache {private List services = new ArrayList (); public MessagingService getService (String serviceName) {// načítať zo zoznamu} public void addService (MessagingService newService) {// pridať do zoznamu}} 

Na záver môžeme implementovať našu triedu vyhľadávačov služieb:

public class ServiceLocator {private static Cache cache = new Cache (); public static MessagingService getService (String serviceName) {MessagingService service = cache.getService (serviceName); if (service! = null) {vrátiť službu; } InitialContext context = nový InitialContext (); MessagingService service1 = (MessagingService) kontext. Lookup (serviceName); cache.addService (služba1); spiatočná služba1; }}

Logika je tu dosť jednoduchá.

Trieda obsahuje inštanciu súboru Cache. Potom v getService () najskôr skontroluje medzipamäť inštancie služby.

Potom, ak je to tak nulový, zavolá inicializačnú logiku a pridá nový objekt do medzipamäte.

4. Testovanie

Pozrime sa, ako teraz môžeme získať inštancie:

Služba MessagingService = ServiceLocator.getService ("EmailService"); Reťazec email = service.getMessageBody (); MessagingService smsService = ServiceLocator.getService ("SMSService"); Reťazec sms = smsService.getMessageBody (); MessagingService emailService = ServiceLocator.getService ("EmailService"); Reťazec newEmail = emailService.getMessageBody ();

Prvýkrát dostaneme EmailService z ServiceLocator vytvorí sa a vráti sa nová inštancia. Potom, ako to zavoláte nabudúce, EmailService bude vrátený z cache.

5. Vyhľadávač služieb vs Injekcia závislostí

Na prvý pohľad môže vzor Service Locator vyzerať podobne ako iný dobre známy vzor - konkrétne Dependency Injection.

Najskôr je dôležité si to uvedomiť ako Dependency Injection, tak vzor Service Locator sú implementáciami konceptu inverzie riadenia.

Než pôjdete ďalej, v tomto dokumente sa dozviete viac o Injekcii závislostí.

Kľúčovým rozdielom je, že objekt klienta stále vytvára svoje závislosti. Používa na to iba lokátor, čo znamená, že potrebuje odkaz na lokátor.

Na porovnanie, pri použití injektáže závislostí sa triede zadajú závislosti. Injektor sa pri spustení zavolá iba raz, aby sa do triedy vložili závislosti.

Na záver zvážime niekoľko dôvodov, prečo sa vyhnúť použitiu vzoru vyhľadávača služieb.

Jedným z argumentov je, že sťažuje testovanie jednotiek. Pomocou injekcie závislostí môžeme odovzdať falošné objekty závislej triedy testovanej inštancii. Na druhej strane je to úzke miesto so vzorom vyhľadávača služieb.

Ďalším problémom je, že je zložitejšie používať API založené na tomto vzore. Dôvod je ten, že závislosti sú skryté vo vnútri triedy a overujú sa iba za behu programu.

Napriek tomu všetkému je vzor Service Locator ľahko kódovateľný a zrozumiteľný a môže byť skvelou voľbou pre malé aplikácie.

6. Záver

Táto príručka ukazuje, ako a prečo používať návrhový vzor vyhľadávača služieb. Diskutuje o hlavných rozdieloch medzi návrhovým vzorom vyhľadávača služieb a konceptom Dependency Injection.

Všeobecne je na vývojárovi, aby rozhodol, ako navrhne triedy v aplikácii.

Vzor vyhľadávača služieb je priamy vzor na oddelenie kódu. V prípade použitia tried vo viacerých aplikáciách je však injekcia závislostí správnou voľbou.

Kompletný kód je ako obvykle k dispozícii v projekte Github.