find(date);
if (wd != null)
return new Double(wd.getHigh());
return null;
}
}
Spring Framework. Profesjonalne tworzenie oprogramowania w Javie
Gdybyśmy tego nie zrobili, metoda za każdym razem zwracałaby ten sam egzemplarz singletonu (składowany w pamięci podręcznej). Takie rozwiązanie jest co prawda poprawne, jednak jest mało prawdopodobne, byś kiedykolwiek chciał uzyskać właśnie taki efekt, ponieważ podstawową zaletą techniki wstrzykiwania metod wyszukujących jest możliwość wstrzykiwania prototypów (niesingletonów), jak choćby w analizowanym przykładzie. W tym przypadku klasa WeatherServiceImpl i metoda getWeatherDao() są abstrakcyjne, możemy jednak przykryć dowolną metodę zwracającą każdego komponentu JavaBean (w praktyce metody kandydujące nie muszą pobierać żadnych argumentów, a ich nazwy nie muszą nawet być zgodne z konwencją nazewnictwa JavaBeans, choć ze względu na klarowność kodu takie rozwiązanie jest zalecane). Warto pamiętać, że także pozostały kod aplikacji musi korzystać z naszej metody zwracającej (a nie z odpowiedniego pola) do uzyskiwania dostępu do obiektu DAO. Wywoływanie metod zamiast bezpośredniego odwoływania się do pól obiektów jest jeszcze jedną dobrą praktyką przetwarzania właściwości komponentów JavaBeans.
Stosując techniki wstrzykiwania metod, warto odpowiedzieć sobie na pytanie, jak można testować kod (np. wykonywać testy jednostkowe) aplikacji bez kontenera, który wstrzykuje daną metodę. Podobne wątpliwości są szczególnie istotne w przypadku aplikacji podobnych do analizowanej usługi pogodowej, gdzie klasa implementacji jest abstrakcyjna. Stosunkowo prostą i jednocześnie możliwą do zrealizowania strategią przeprowadzania testów jednostkowych w podobnych przypadkach jest stworzenie dla wspomnianej klasy abstrak-cyjnej podklasy zawierającej testową implementację metody, która w normalnych warunkach jest wstrzykiwana, przykładowo:
...
WeatherService ws = new WeatherServiceImpl() {
protected WeatherDao getWeatherDao() {
// zwraca obiekt DAO dla danego testu
...
}
};
Stosowanie przez użytkowników Springa tak zaawansowanych mechanizmów jak wstrzykiwanie metod zawsze powinno być poprzedzone dogłębną analizą — należy zdecydować, które rozwiązanie w danej sytuacji jest najbardziej uzasadnione i które nie będzie stanowiło niepotrzebnego utrudnienia dla programistów. Niezależnie od wyników tej analizy naszym zdaniem przedstawione powyżej podejście jest pod wieloma względami lepsze od umieszczania w kodzie aplikacji zależności od interfejsów API kontenera.
88
D:\! AAA DZISIAJ\Spring Framework. Profesjonalne tworzenie oprogramowania w Javie\9 druk\r02.doc
Rozdział 2. n Fabryka komponentów i kontekst aplikacji 89
Wybór pomiędzy wstrzykiwaniem
przez metody ustawiajÄ…ce a wstrzykiwaniem przez konstruktory
Podczas korzystania z istniejących klas może się zdarzyć, że nie będziesz nawet miał wyboru pomiędzy użyciem techniki wstrzykiwania przez metody ustawiające a zastosowaniem wstrzykiwania przez konstruktor. Jeśli dana klasa zawiera wyłącznie wieloargumentowy konstruktor i żadnych właściwości komponentu JavaBean lub jednoargumentowy konstruktor i proste właściwości JavaBean, wybór metody wstrzykiwania nie zależy od Ciebie
— dokonano go już wcześniej. Co więcej, niektóre spośród istniejących klas mogą wymuszać stosowanie kombinacji obu form wstrzykiwania zależności, gdzie oprócz wieloargu-mentowego konstruktora będziesz zobligowany do ustawienia kilku opcjonalnych właści-wości JavaBean.
Jeśli masz wybór odnośnie wersji wstrzykiwania zależności, której chcesz użyć lub dla której chcesz zaprojektować architekturę swojej aplikacji, przed podjęciem ostatecznej decyzji powinieneś wziąć pod uwagę kilka czynników:
n Stosowanie właściwości JavaBean generalnie ułatwia obsługę domyślnych lub opcjonalnych wartości w sytuacji, gdy nie wszystkie wartości faktycznie są wymagane.
W przypadku wstrzykiwania przez konstruktor takie podejście musiałoby prowadzić do stworzenia wielu wariantów konstruktora, gdzie jeden konstruktor wywoływałby w swoim ciele inny. Wiele wersji konstruktora i długie listy argumentów mogą być zbyt rozwlekłe i utrudniać konserwację kodu.