Service Locator vs Dependency Injection
Service Locator vs Dependency Injection
Service Locator (lokalizator usług) i Dependency Injection (wstrzykiwanie zależności) to wzorce które realizują koncepcję Inversion Of Control (odwrócenie sterowania). Na wstępie zaznaczam, że Service Locator to moim zdaniem antywzorzec i nie powinien być stosowany co udowodnię w tym artykule. Na początek przykładowa implementacja wzorca Service Locator.
Implementacja wzorca Service Locator:
public interface Service { String getName(); }
Implementacja przykładowych serwisów:
public class ServiceFirstImpl implements Service { public String getName() { return "ServiceFirstImpl"; } }
public class ServiceSecondImpl implements Service { public String getName() { return "ServiceSecondImpl"; } }
Wyszukiwanie serwisów na podstawie ich nazwy czyli klasa Context:
public class Context { public Object lookup(String jndiName){ if(jndiName.equalsIgnoreCase("ServiceFirstImpl")){ return new ServiceFirstImpl(); } else if (jndiName.equalsIgnoreCase("ServiceSecondImpl")){ return new ServiceSecondImpl(); } return null; } }
Klasa która dodaje serwisy do pamięci podręcznej – cache:
public class Cache { private List<Service> services; public Cache(){ services = new ArrayList<Service>(); } public Service getService(String serviceName){ List<Service> servicesFilter = services.stream().filter( service -> service.getName().equalsIgnoreCase(serviceName) ).collect(Collectors.toList()); if(servicesFilter.isEmpty()) { return null; } else { return servicesFilter.get(0); } } public void addService(Service newService){ boolean exists = false; for (Service service : services) { if(service.getName().equalsIgnoreCase(newService.getName())){ exists = true; } } if(!exists){ services.add(newService); } } }
Kluczowa klasa ServiceLocator:
public class ServiceLocator { private static Cache cache; static { cache = new Cache(); } public static Service getService(String jndiName){ Service service = cache.getService(jndiName); if(service != null){ return service; } Context context = new Context(); Service service1 = (Service)context.lookup(jndiName); cache.addService(service1); return service1; } }
przypomnienie – blok statyczny wywoływany jest w momencie pierwszego odwołania do jednej ze składowych statycznych klasy.
Testy aplikacji:
public class ServiceLocatorPatternDemo { public static void main(String[] args) { Service service = ServiceLocator.getService("ServiceFirstImpl"); System.out.println(service.getName()); service = ServiceLocator.getService("ServiceSecondImpl"); System.out.println(service.getName()); service = ServiceLocator.getService("ServiceFirstImpl"); System.out.println(service.getName()); service = ServiceLocator.getService("ServiceSecondImpl"); System.out.println(service.getName()); } }
wynik:
ServiceFirstImpl ServiceSecondImpl ServiceFirstImpl ServiceSecondImpl
W czym tkwi problem?
Dużym problemem użycia wzorca Service Locator w stosunku do wzorca wstrzykiwania zależności jest konieczność modyfikacji kodu źródłowego komponentów w przypadku zamiany lub refaktoryzacji biblioteki realizującej zadania kontenera IoC.
class PDFDocument { public void printPDF(Document document) { PrintManager printerManager = ServiceLocator.getService("PrinterManagerImpl"); printerManager.print(document); } }
w sytuacji kiedy wywołujemy metodę prrintPDF i nie został zarejestrowany wcześniej obiekt (z ang. bean) PrinterManagerImpl uzyskujemy błąd na etapie wykonania – Runtime! Należy zatem pamiętać o prawidłowym zarejestrowaniu obiektów co bez wnikania w dokumentację jest po prostu niemożliwe. Ponadto zależności są ukryte w klasach. Tracimy również możliwość testowania kodu z użyciem testów jednostkowych. Kolejna sprawa dotyczy refaktoringu. Jeśli metoda printPDF zostanie zmodyfikowana i zacznie wykorzystywać kolejne zależności to może dojść do sytuacji, że program przestanie działać i to nie na etapie kompilacji, ale na etapie wykonania.
Jeśli jednak zamienimy powyższy kod na:
class PDFDocument { private PrintManager printerManager; PDFDocument(PrintManager printerManager){ this.pronterManager = printerManager; } public void printPDF(Document document) { printerManager.print(document); } }
to od razu widać w jaki sposób obiekty powinny być tworzone – że PDFDocument zależy od PrinterManagera. Należy zatem w przypadku testów jednostkowych utworzyć Stub’a dla PrintManagera. Ponadto jesteśmy w stanie wykryć błędy już na etapie kompilacji!
Leave a comment