Wyobraźmy sobie, że nasza aplikacja często wykorzystuje klasę NewsService. Co to oznacza w praktyce? Za każdym razem musimy wstrzykiwać do niej zależność, których potrzebuje. Nasz przykład jest dość prosty, zależności nie ma zbyt wiele, ale nawet tutaj powtarzanie przy każdym użyciu kodu

public class Client {
  public static void main(String[] args) {
    Authenticator authenticator = new UsernamePassAuthenticator("beer","beer");
    Driver driver = new SqlDbDriver();

    //inject dependency #1
    Storage storage = new DBStorage(driver);
    //inject dependency #2
    NewsService newsService = new NewsService(storage);
    //inject dependency #3
    newsService.setAuthenticator(authenticator);

    newsService.addNews("ble ble ble");
  }
}

nie jest zbyt zachęcające. Czy nie lepiej jest użyć jednak jakiego wzorca factory czy service locator, żeby jednak NewsService sam sobie znalazł potrzebne klasy?

Okazuje się, że problem można rozwiązać bez rezygnowania z DI wykorzystując kontenera Dependency Injection, taki jak Spring, PicoContainer czy Google Guice.

Cóż takiego nadzwyczajnego robią te kontenery, że ludzie ich używają. Ich działanie tak na prawdę sprowadza się do tego, że pozwalają w jakiś sposób w jednym miejscu powiedzieć, że dana klasa potrzebuje konkretnej implementacji interfejsu lub interfejsów.

W naszym przykładzie chcemy wskazać, że NewsService potrzebuje klasy DBStorage, która implementuje Storage, a klasa DBStorage potrzebuje klasy SqlDbDriver, implementującej interfejs Driver.

Kontenery różnią się od siebie sposobem definiowania zależności między klasami. Spring pozwala konfigurować te zależności w pliku XML-owym lub (od niedawna) przy pomocy metadanych (ang. annotations). Google Guice jest nowszym rozwiązaniem i bazuje na wykorzystaniu metadanych.

Można, rzecz jasna, napisać własnych “kontener DI”, czyli pojedynczą klasę, w której będzie zawarta informacją o zależnościach między klasami, ale to oznacza dodatkową pracę, zastanawianie się na ile nasz pomysł na kontener będzie uniwersalny, itp.

Zaletą centralnej konfiguracji zależności jest możliwość ich podmieniania w razie potrzeby. Na przykład na potrzeby testów możemy jako implementacji Storage używać jakiejś naszej klasy, która udaje Storage na tyle, na ile jest to potrzebne do testów jednostkowych czy funkcjonalnych. Dzięki temu testy wykonują się szybciej, nie jest potrzebna baza danych.

Dodatkowo, jeżeli klient zażyczy sobie, żeby dane były przechowywane w plikach tekstowych, a nie bazie danych, to wystarczy, że napiszemy odpowiednie implementację Storage i/lub Driver i zmienimy konfigurację wstrzykiwania zależności w ten sposób, żeby były użyte nowe implementacje.

Oczywiście nie ma nic za darmo, to my musimy utrzymywać plik konfiguracyjny, który potrafi być całkiem pokaźnych rozmiarów w większej aplikacji lub pilnować aktualizacji parametrów odpowiednich metadanych.

Swoją drogą jest jedna technologia, w której mamy do dyspozycji DI, a nie musimy sami nic konfigurować – to te paskudne EJB, przez wielu szczerze znienawidzone. Tam po prostu serwer aplikacji przechowuje informację o komponentach, które mają być udostępniane w ramach aplikacji i jeżeli chcemy jakiegoś komponentu użyć, to po prostu odwołujemy się do niego poprzez interfejs, a serwer sam nam wstrzykuje odpowiedni obiekt:

@Stateless
public class PierwszyBean implements PierwszyBeanInterfejs {
  //implementację DrugiBean wstrzyknie sam serwer aplikacji
  @EJB DrugiBeanInterfejs drugiBean;

  public void metoda(){
    drugiBean.zrobCos();
  }
}

Nie mamy żadnego pliku konfiguracyjnego, w którym byśmy mogli godzinami szukać źle zdefiniowanych zależności ;).

Ok, tak na serio pilnowanie zależności nie jest aż tak bardzo straszne. Użycie kontenerów zazwyczaj jednak ułatwia życie, zobaczmy więc jak działa najpopularniejszy z nich: Spring.

Pierwsza rzecz, to musimy sobie ściągnąć ze strony http://www.springsource.org/ Spring Framework. Ja używałem wersji 2.5.X.

Prościej sprawę można załatwić używając rozsądnego IDE, które ma wbudowane wsparcie dla Spring-a. W paczce dostajemy to razem z NetBeans, MyEclipse IDE, IntelliJ Idea. Jak ktoś używa Eclipse, to można sobie doinstalować odpowiednią wtyczkę. Użycie IDE ma głęboki sens, bo dostajemy podpowiadanie składni w XML-owym pliku konfiguracyjnym, a czasem nawet wizualne narzędzie, które pozawala łatwiej oglądać zależności.

Zakładamy zatem, że mamy na ścieżce klas dodane biblioteki Spring-a.

Co teraz? Czy musimy jakoś modyfikować klasy które już napisaliśmy? Na szczęście nie, nasza aplikacja używa już DI, więc nawet linijki kodu ruszyć nie musimy. Zrobić musimy dwie rzeczy. Po pierwsze musimy zadeklarować zależności między klasami. Po drugie musimy zrobić użytek z tej konfiguracji modyfikując odpowiednio klasę Client, która używa NewsService.

Zacznijmy od konfiguracji. Plik może mieć dowolną nazwę, tutaj jest to springXMLConfig.xml, a jego zawartość widzimy na poniższym listingu:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

  <bean name="sqldriver" class="pl.erudis.newsservice.di.drivers.SqlDbDriver"/>

  <bean name="dbstorage" class="pl.erudis.newsservice.di.storage.DBStorage">
    <constructor-arg ref="sqldriver"/>
  </bean>

  <bean name="upauth" class="pl.erudis.newsservice.di.auth.UsernamePassAuthenticator" />

  <bean name="newsService" class="pl.erudis.newsservice.di.NewsService" >
    <property name="authenticator" ref="upauth"/>
    <property name="storage" ref="dbstorage"/>
  </bean>
</beans>

Co się tutaj dzieje. Na początku deklarujemy użycie klasy SqlDbDriver. Podobnie deklarujemy użycie klasy DBStorage, dodatkowo zaznaczamy, że klasa DBStorage będzie używała klasy SqlDbDriver. Odpowiada za to element

Mówi on Springowi, żeby przy inicjalizacji klasy DBStorage do konstruktora “wstrzyknął” obiekt wskazanej przez nas klasy, czyli SqlDbDriver.

Dalej wszystko robimy analogicznie, deklarujemy użycie klasy UsernamePassAuthenticator, a następnie informujemy Spring, że NewsService potrzebuje klas DBStorage oraz UsernamePassAuthenticator. W tym przypadku obiekty klas nie są przekazywane jako parametry konstruktora, tylko inicjalizują pola klasy NewsService, używając odpowiednich metod “set” dla pól.

Wreszcie nadszedł czas na nagrodę, czyli wykorzystanie Springa do zarządzania zależnościami, zobaczmy jak wygląda teraz klasa kliencka:

package pl.erudis.newsservice.di;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

/**
 *
 * @author Piotr Kochański, www.xoft.pl
 */
public class SpringClient {
  public static void main(String[] args) {
    ApplicationContext factory = new ClassPathXmlApplicationContext("META-INF/springXMLConfig.xml");
    NewsService newsService = (NewsService)factory.getBean("newsService");
    newsService.getAuthenticator().login(new String[]{"beer", "beer"});
    newsService.addNews("bla bla spring bla");
  }
}

Pierwszym krokiem jest inicjalizacja Springa, jest to robione przy użyciu klasy ApplicationContext – musimy po prostu powiedzieć Springowi, żeby wczytał z pliku konfiguracyjnego zestaw zależności. Zgodnie z często używaną konwencją plik konfiguracyjny Springa jest w katalogu META-INF, który muszą “widzieć” skompilowane klasy Java.

Po inicjalizacji zostaje już nie wiele do zrobienia, wyciągamy klasę, która nas interesuje, czyli NewsService przy pomocy ApplicationContext przekazując mu nazwę tej klasy skonfigurowaną w springXMLConfig.xml. Spring automatycznie przekaże do NewsService potrzebne zależności i dalej używamy jej zapominając o DI czy Springu.

Zaleta wykorzystania kontenera DI jest jasna – mamy spójny sposób deklarowania zależności między komponentami, dzięki czemu pisząc kod możemy się koncentrować na jego faktycznej funkcjonalności, a nie pilnować odpowiednich związków z innymi klasami.

Oczywiście Spring nie jest tylko samym kontenerem DI, potrafi znacznie więcej rzeczy, ale tutaj nas interesował tylko ten jego aspekt.

Źródła przykładowej aplikacji można ściągnąć klikając tutaj, jeżeli ktoś woli, to jest także do pobrania projekt NetBeans-a w wersji 6.5, który zawiera tę aplikację.

W kolejnej części cyklu zobaczymy w jaki sposób użyć kontenera Google Guice do zarządzania zależnościami w DI.

Co to w ogóle jest, po co takie coś komukolwiek, jak tego używać? Okazuje się, że sprawa jest prosta, wręcz banalna, a jednocześnie prowadzi do całkiem interesujących zastosowań. Za chwilę postaramy się zrozumieć jak DI działa, zrobimy to w sposób praktyczny, obdarty z krążących wokół DI ideologii i zupełnie zbędnego adżajlowego bełkotu.

Przekonamy się, że DI jest jednym z wielu możliwych sposobów budowania architektury aplikacji tak, by była łatwa w rozbudowie i testowaniu.

Będziemy chcieli zobaczyć coś więcej, niż zupełnie trywialny przykład (takich jest mnóstwo w internecie), po którym w zasadzie można wzruszyć ramionami, bo nie specjalnie widać tam jakiekolwiek zalety architektury wykorzystującej DI.

Naszym celem będzie zbudowanie bardzo prostej aplikacji służącej do przechowywania informacji, będzie składała się ona z trzech warstw (trójka jest nieprzypadkowa, sporo aplikacji Java EE jest rozbijane na tyle warstw) i tyluż komponentów.

Naszą aplikację napiszemy na kilka sposobów:

• naiwne podeście z paskudną architekturą;
• w miarę rozsądnie wyglądająca aplikacja, wykorzystująca wstrzykiwanie zależności;
• aplikacja wykorzystująca wstrzykiwanie zależności, ale zrobiona źle – warto wiedzieć, że wbrew wrażeniu, jakie można odnieść po ohah i ahah na temat DI, przy jego pomocy też można koncertowo skopać architekturę tworzonego oprogramowania.
• ta sama aplikacja, wykorzystująca wstrzykiwanie zależności i kontener Spring;
• jeszcze raz to samo, ale z wykorzystaniem Google Guice;
• następnie spróbujemy porównać działanie Spring i Google Guice;
• wreszcie, na końcu trochę “filozofii”, czy faktycznie DI jest potrzebne, czy jest potrzebne tylko Javie, jak to jest z innymi językami.

Zatem, do dzieła!

Zaczniemy od pierwszej wersji naszej aplikacji. Głównym jej elementem jest klasa NewsService, która używa do przechowywania informacji klasy DBStorage, która to z kolei potrzebuje sterownika komunikującego się z bazą danych (DBDriver). Chcemy mieć także możliwość zmuszenia użytkownika naszej aplikacji do uwierzytelnienia się – zajmuje się tym DBStorage i NewsService.

Zobaczmy sobie po kolei te klasy:

public class NewsService {
  DBStorage dBStorage = new DBStorage();

  public void addNews(String news){
    addNews(news, new DBStorage());
  }

  public void addNews(String news, String uname, String pass){
    addNews(news, new DBStorage(uname, pass));
  }

  public void addNews(String news, DBStorage dBStorage){
    this.dBStorage = dBStorage;
    dBStorage.save(news.getBytes());
  }
}

W tej klasie ważne są dwie rzeczy: użycie DBStorage oraz oczywiście metoda addNews.

public class DBStorage {

  DBDriver driver;

  public DBStorage(String uname, String pass) {
    authenticate(uname, pass);
    driver = DBDriver.getInstance();
  }

  public DBStorage() {
    driver = DBDriver.getInstance();
  }

  public void authenticate(String uname, String pass){
    System.out.println("Authentication...");
  }

  public void save(byte[] data){
    driver.openConnection();
    System.out.println("Saving in database...");
    driver.closeConnection();
  }
}

Klasa DBStorage dzielnie sama sobie produkuje DBDriver i jeszcze na dodatek zajmuje się uwierzytelnianiem użytkowników. Metoda save wykonuje czarną robotę zapisywania danych w odpowiednim miejscu.

public class DBDriver {

  private DBDriver() {
  }

  public static DBDriver getInstance(){
    return new DBDriver();
  }

  public void openConnection(){
    System.out.println("Openning the connection");
  }

  public void closeConnection(){
    System.out.println("Closing the connection");
  }
}

Zobaczmy też na listingu poniżej jak tego wszystkiego można użyć razem:

public class Client {
  public static void main(String[] args) {
    NewsService newsService = new NewsService();
    newsService.addNews("ble ble ble");

    DBStorage dbStorage1 = new DBStorage();
    newsService.addNews("bla bla bla", dbStorage1);

    DBStorage dbStorage2 = new DBStorage("joe","beer");
    newsService.addNews("bla bla bla", dbStorage2);
  }
}

No dobrze, kod się kompiluje, działa, wydawałoby się, że wszystko jest ok, ale… No właśnie, coś tutaj jednak nie gra.

Pierwsza rzecz. Wyobraźmy sobie, że chcemy teraz zapisywać dane nie w bazie danych tylko, powiedzmy, w pliku XML-owym, albo pliku JSON czy CSV. Albo może nasze newsy mają być przechowywane jako zserializowane obiekty Java. Jednakże klasa NewsService zależy od klasy DBStorage, która potrafi dane przechowywać tylko w bazie danych.

Mało tego, klasa DBStorage jest powiązana ściśle z DBDriver, także podmiana klasy sterownika również nie jest prosta.

Jedyne wyście jakie nam pozostaje, gdy chcemy zmienić sposób działania aplikacji, to dodawać do klasy NewsService kolejne metody dodające informację, które będą wykorzystywały inne sposoby przechowywania danych. Powstanie w ten sposób kod, który będzie się w dużej mierze powtarzał, klasa NewsService będzie się coraz bardziej rozrastała, a jej użycie coraz trudniejsze.

Świetnie, krytykować zawsze jest łatwo. A co, jeśli docelowym sposobem przechowywania informacji jest baza danych i nie będziemy tutaj nic zmieniać?

To nas prowadzi do drugiego problemu – testowalności tej aplikacji. Jedynym sposobem testowania klasy NewsService jest dostarczenie jej instancji klasy DBStorage – bez niej NewsService nie może w ogóle działać. DBStorage z kolei używa konkretnego sterownika do bazy danych.

W rezultacie, jeśli chcemy napisać test jednostkowy, czy test funkcjonalny musimy odtworzyć pełne środowisko działania aplikacji. Jeżeli nawet da się to zrobić (chociaż może wcale tak nie być i często w rzeczywistych sytuacjach nie jest), to testy będą znacznie trudniejsze do napisania, będą dłużej się wykonywały. Przy takiej aplikacji jak nasza, pewnie to nie jest problemem, ale pracując z 500 tysiącami linii kodu może być to istotna sprawa.

Na koniec jeszcze jeden rzecz – problem uwierzytelniania. Abstrahując od tego, że przywiązujemy się tylko do jednego sposobu uwierzytelniania (hasło + nazwa użytkownika), to jeszcze sam proces uwierzytelniania jest rozwleczony pomiędzy klasę NewsService i DBStorage.

Co jest przyczyną wymienionych problemów? Popatrzmy sobie na to, co zrobiliśmy z lotu ptaka:

Teraz widać jaśniej, co zrobiliśmy źle:

• Klasa NewsService zależy od konkretnej implementacji DBStorage, przez co nie możemy go łatwo wymienić na inny typ kontenera na dane.
• DBStorage zależy także bezpośrednio od DBDriver – tutaj sytuacja jest odrobinę lepsza, bo DBDriver jest tworzony przy pomocy metody factory, co daję pewną elastyczność tworzenia tego obiektu. Niestety z punktu widzenia testowalności niewiele to nam daje – chcielibyśmy w miejsce tego sterownika podstawić obiekt symulujący zachowanie sterownika, na co obecna implementacja nie pozwala
• W przypadku uwierzytelniania źle zaplanowaliśmy odpowiedzialność klas i zaszyliśmy na stałe konkretny sposób uwierzytelniania

Jak przemodelować tę aplikację, żeby pozbyć wyeliminować powyżej opisane jej wady? Tym zajmiemy się w kolejnym wpisie.