Wygląda toto faktycznie dobrze, nie da się odróżnić od Flasha, można złośliwie powiedzieć. Jak Oracz zainwestuje w poprawienie narzędzi deweloperskich i sensowną bibliotekę komponentów, to może coś z tego będzie.

Last night I went to the Extreme Programming San Diego meeting (it should probably be called “Agile” but I suspect the group is old enough that XP was what started it). A reader knew that I was in San Diego visiting my folks so he suggested it. I thought I’d dip my toe in the water and see if programming was any more interesting to me than the last time I checked. Especially since Agile practices tend to be more focused on people issues, which is where I seem to continue to drift.

The first thing I noticed was the turnout. I’m guessing there are thousands of programmers in San Diego, but we got maybe 10 people to show up.

Chyba w San Diego już się połapali, że 90% Agile to wynalazek cwanych konsultantów… 10 osób to i tak niezły wynik.

Weźmy NetBeans. Oracle ogłosił:

Oracle will invest in the NetBeans IDE and NetBeans.org community, but it will be limited to Java Standard Edition, scripting languages, mobile Java, JavaFX and Solaris. Oracle’s own Java IDE, JDeveloper IDE, will be Oracle’s enterprise application development tool.

Czyli NetBeans będzie środowiskiem programistycznym do wszystkiego, tylko nie do Java EE. Ponieważ gro aplikacji Javowych jest pisanych właśnie w Java EE, to praktycznie oznacza utrupienie NetBeans na rzecz JDevelopera. Kto będzie chciał się wozić ze środowiskiem Javowym, w którym nie można napisać aplikacji JEE? Szkoda.

GlassFish ma być wspierany i rozwijany, ale jako serwer do aplikacji intranetowych:

WebLogic will be sold as the company’s enterprise application server, while the free and open source Glassfish server will be Oracle’s department-level application server.

Myślałem, że Oracle będzie chciał podgryzać GlassFishem JBoss-a, ale wygląda na to, że nie. W takim razie, kto będzie chciał się bawić w serwer, który w założeniu ma być “gorszy” od WebLogic-a. GlassFish, czyli tak na prawdę Sun GlassFish Enterprise Server (dawniej Sun ONE Application Server), jakoś szczególnie nie ustępuje WebLogicowi, co więc zamierza Oracle? Ma już dwa serwery aplikacyjne, teraz dochodzi trzeci; obawiam się, że GlassFish może szybo odejść w odstawkę pod pretekstem nie przynoszenia zysków. Chyba, że faktycznie Oracle ma jakiś dobry pomysł na niego.

Wygląda na to, że z kolei Oracle zamierza inwestować w JavaFX. To akurat mocno mnie dziwi, bo póki co na tle Silverlighta czy Flex-a JavaFX nie wygląda najlepiej, przynajmniej od strony potencjału bycia czymś równie popularnym, jak konkurenci. Technologicznie JavaFX jest bardzo fajnym pomysłem, ale funkcjonalność, dostępne komponenty są lata świetlne za innymi wynalazkami. Może tutaj Oracle ma jakiś ciekawy pomysł na biznes?

Dzięki temu, że NewsService zależy od interfejsów, a nie klas konkretnych możemy wstrzykiwać mu taką implementację danego interfejsu, jaka jest potrzebna w określonej sytuacji. Jak stwierdziliśmy, ręczne wstrzykiwanie na dłuższą metę jest męczące, w związku z tym postanowiliśmy użyć do tego celu Spring-a. Działa on w ten sposób, że w pliku konfiguracyjnym określamy zależności między klasami, które potem Spring już samodzielnie wstrzykuje we wskazana miejsce.

Podejście użyte przez Spring-a ma parę wad. Po pierwsze jest XML-owy plik konfiguracyjny, który musi być zsynchronizowany z kodem. Można w nim zrobić pomyłkę (dobre IDE pomaga unikać błędów), refaktoryzacja kodu jest utrudniona – dobre IDE pozwala w miarę niezawodnie przeprowadzać tę operację, ale czasem i ono może pomylić się, w końcu XML to tylko łańcuchy znaków. Wreszcie do pliku Springa czasem trzeba dodać więcej informacji, niż to jest tak na prawdę potrzebne (wersja 2.0 ograniczyła ten problem).

Czy można zrobić kontener DI lepiej? Narzuca się oczywiście użycie metadanych (ang. annotations), w końcu od Java 5.0 jest to nowa, skuteczna metoda kontroli zachowania aplikacji w określonym środowisku.

Warto się zastanowić dwa razy nad użyciem tego mechanizmu, bo zewnętrzna konfiguracja wcale nie jest taką złą rzeczą. Na przykład kwerendy nazwane dla JPA zdecydowanie wygodniej jest definiować w pliku, mimo, że można użyć metadanych.

Zobaczymy jednak, że Google Guice oferuje nam rozwiązanie, bazujące na wykorzystaniu metadanych, które faktycznie jest wygodniejsze w użyciu niż Spring.

Jak działa Guice? W kodzie umieszczamy metadane, które mówią gdzie potrzebujemy wstrzyknięcia zależności. Zajmuje się tym metadana @Inject.

Samo powiedzenie, że nasza klasa potrzebuje wstrzyknięcia instancji innej klasy to jeszcze za mało. Musimy powiedzieć o jaką konkretną implementację nam chodzi. W przypadku Spring-a ta informacja była zaszyta w konfiguracji w pliku XML. Google Guice podchodzi do tego tematu inaczej. Definicje zależności między klasami umieszczamy w osobnej klasie Java – module Guice. Dzięki temu definicje te są odporne na literówki i poddają się bezboleśnie refaktoryzacji.

Zobaczmy jak to wygląda w praktyce. Pierwsza rzecz, to trzeba pobrać Google Guice i dołączyć zawarte w ściągniętej paczce pliki JAR do ścieżki swojego projektu.

Gdy mamy już skonfigurowany do pracy projekt jesteśmy gotowi zacząć pracę z Guice. Przede wszystkim musimy zmodyfikować klasę NewsService:

import com.google.inject.Inject;
import pl.erudis.newsservice.di.storage.Storage;
import pl.erudis.newsservice.di.auth.Authenticator;

public class NewsService {

  Storage storage;
  Authenticator authenticator;

  public NewsService() {
  }

  public NewsService(Storage storage) {
    this.storage = storage;
  }

  public Authenticator getAuthenticator() {
    return authenticator;
  }

  @Inject
  public void setAuthenticator(Authenticator authenticator) {
    this.authenticator = authenticator;
  }

  public Storage getStorage() {
    return storage;
  }

  @Inject
  public void setStorage(Storage storage) {
    this.storage = storage;
  }

  public void addNews(String news){
    if(authenticator != null){
      authenticator.authenticate();
    }
    storage.save(news.getBytes());
    System.out.println("News saved...");
  }
}

Klasa ta w zasadzie nie zmieniła się w stosunku do wersji używanej ze Springiem, czy w ogóle bez kontenera DI, jedyna rzecz, która się pojawiła, to metadana @Inject w tych miejscach, gdzie potrzebne jest nam wstrzyknięcie instancji odpowiedniej klasy.

Jest to bardzo ważna rzecz: użycie Guice tak jak Springa nie wymaga zmian w kodzie – metadane to nie jest tak na prawdę zmiana kodu, tylko szczególny sposób konfiguracji aplikacji na potrzeby jakiegoś narzędzia.

Podobnie musimy zmodyfikować klasę DBStorage:

import com.google.inject.Inject;
import pl.erudis.newsservice.di.drivers.Driver;

public class DBStorage implements Storage{

  Driver driver;

  @Inject
  public DBStorage(Driver driver) {
    this.driver = driver;
  }

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

}

Teraz pozostaje tylko powiedzieć co ma być wstrzykiwane w oznaczone metadaną @Inject miejsca. W tym celu definiujemy moduł:

import com.google.inject.Binder;
import com.google.inject.Module;
import pl.erudis.newsservice.di.auth.Authenticator;
import pl.erudis.newsservice.di.auth.UsernamePassAuthenticator;
import pl.erudis.newsservice.di.drivers.Driver;
import pl.erudis.newsservice.di.drivers.SqlDbDriver;
import pl.erudis.newsservice.di.storage.DBStorage;
import pl.erudis.newsservice.di.storage.Storage;

public class NewsServiceModule implements Module{

  public void configure(Binder binder) {
    binder.bind(Authenticator.class).to(UsernamePassAuthenticator.class);
    binder.bind(Driver.class).to(SqlDbDriver.class);
    binder.bind(Storage.class).to(DBStorage.class);
  }
}

Moduł wiąże ze sobą interfejsy, których używamy w kodzie z konkretnymi implementacjami, wybranymi przez nas w danej sytuacji. Warto zwrócić uwagę na bardzo inteligentnie wybrane nazwy metod. Kod czyta się jak narrację, w końcu język programowania ma być językiem. Trudno się nie połapać co oznacza kod “powiąż Authenticator.class z UsernamePassAuthenticator.class”.

Widać też od razu, że bardzo łatwo dynamicznie tworzyć powiązania – wszystko robimy w kodzie Java.
Wreszcie ostatni element, czyli klasa kliencka

import com.google.inject.Guice;
import com.google.inject.Injector;

public class GuiceClient {
  public static void main(String[] args) {
    Injector i = Guice.createInjector(new NewsServiceModule());
    NewsService newsService = i.getInstance(NewsService.class);
    newsService.getAuthenticator().login(new String[]{"beer", "beer"});
    newsService.addNews("bla bla guice bla");
  }
}

Zarówno klasa kliencka jak i definicja modułów mają bardzo istotną zaletę w stosunku do Spring-a – nigdzie nie występują łańcuchy znaków reprezentujące klasy. Używały wyłącznie kompilowalnych artefaktów, dzięki czemu automatycznie odpada nam cała klasa przykrych błędów.

Jeżeli ktoś interesuje się działaniem Spring Framework, to pewnie wie, że od pewnego czasu także Spring może być konfigurowany przy pomocy metadanych, są jednak bardzo zasadnicze różnice pomiędzy sposobem robienia tego przez Spring-a i przez Guice, o tym będziemy mówić w kolejnym odcinku naszej serii.

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.

Zastanówmy się na ile użycie wstrzykiwania zależności czyni nasze oprogramowanie odpornym na błędy przy projektowaniu architektury aplikacji. W końcu nawet najwspanialszy wzorzec projektowy nie zabroni nam popełniania błędów.

Przyjrzyjmy się nieco zmodyfikowanej klasie NewsService

public class NewsService {

  Storage storage;
  Authenticator authenticator;

  public NewsService(Driver driver) {
    storage = new DBStorage(driver);
  }

  public Authenticator getAuthenticator() {
    return authenticator;
  }

  public void setAuthenticator(Authenticator authenticator) {
    this.authenticator = authenticator;
  }

  public void login(String uname, String pass){
    ((UsernamePassAuthenticator)authenticator).setUname(uname);
    ((UsernamePassAuthenticator)authenticator).setPass(pass);
  }

  public void addNews(String news){
    if(authenticator != null){
      authenticator.authenticate();
    }
    storage.save(news.getBytes());
    System.out.println("News saved...");
  }
}

Różni się ona od poprzedniej wersji w jednym drobnym, ale bardzo istotnym szczególe. Klasa NewsService w konstruktorze pobiera jako parametr sterownik (obiekt Driver), a nie, jak poprzednio Storage. W rezultacie NewsService sam sobie musi utworzyć obiekt Storage.

Kod NewsService jest wówczas związany na sztywno z konkretną implementacją kontenera na dane DBStorage, co jest oczywiście niepożądane. Co się zatem stało, co zrobiliśmy nie tak – w końcu używamy DI? A no popełniliśmy błąd polegający na tym, że wstrzykujemy do NewsService nie ten obiekt, co trzeba!

NewsService nie potrzebuje do niczego informacji o użytym sterowniku, NewsService potrzebuje tylko konkretnej implementacji Storage i to ona już ma się martwić o sterownik.

Ok. tutaj przypadek był prosty i ewidentny. W większych aplikacjach łatwo popełnić błąd polegający na wstrzyknięciu nie tego obiektu, który tak na prawdę jest wymagany. Także jeżeli widzimy, że gdzieś inicjalizacja klasy wymaga tworzenia obiektów, albo przekazujemy klasie jako parametr obiekty, które, logicznie rzecz biorąc, nie są jej potrzebne, to znaczy, że gdzieś położyliśmy architekturę aplikacji i błędnie użyliśmy DI.

Użycie DI wcale nie uwalnia nas od dobrego zaprojektowania aplikacji!

Co nas najbardziej uwierało w poprzedniej wersji aplikacji? Tak na prawdę były to dwie rzeczy:

1. Powiązania między klasami były zrealizowane przy użyciu referencji do konkretnych klas: jeżeli NewsService potrzebował mechanizmu do przechowywania informacji, to dawaliśmy mu referencję do klasy, która potrafiła przechowywać dane w SQL-owej bazie danych. Zmiana sposobu przechowywania danych na inny wymagała zmian w wielu miejscach w kodzie.
2. Jeżeli klasa potrzebowała do pracy innej klasy, to sama musiała sobie utworzyć odpowiedni obiekt: NewsService potrzebując klasy do przechowywania danych sam sobie tworzył jej instancję.

Co w takim razie robi wstrzykiwanie zależności? Mówiąc ogólnie, w DI chodzi o to, żeby nie wiązać się z inną klasą poprzez użycie jej implementacji, tylko poprzez interfejs, pod który można podpiąć dowolną klasę go implementującą.

Dodatkowo, jeżeli nasza klasa potrzebuje konkretnej implementacji tego interfejsu, to nie powinna tej implementacji sama szukać czy jej tworzyć. Odpowiedni obiekt musi zostać do klasy “wstrzyknięty” w momencie inicjalizacji.

Zobaczmy, jak to wygląda w praktyce.

Zacznijmy od klasy NewsService, której bezpośrednio używają klasy “interfejsu użytkownika”:

public class NewsService {

  Storage storage;
  Authenticator authenticator;

  public NewsService() {
  }

  public NewsService(Storage storage) {
    this.storage = storage;
  }

  public Authenticator getAuthenticator() {
    return authenticator;
  }

  public void setAuthenticator(Authenticator authenticator) {
    this.authenticator = authenticator;
  }

  public Storage getStorage() {
    return storage;
  }

  public void setStorage(Storage storage) {
    this.storage = storage;
  }

  public void login(String uname, String pass){
    ((UsernamePassAuthenticator)authenticator).setUname(uname);
    ((UsernamePassAuthenticator)authenticator).setPass(pass);
  }

  public void addNews(String news){
    if(authenticator != null){
      authenticator.authenticate();
    }
    storage.save(news.getBytes());
    System.out.println("News saved...");
  }
}

Pierwsza rzecz, którą zrobiliśmy, to usunęliśmy referencje do konkretnej implementacji klasy odpowiedzialnej za przechowywanie danych (DBStorage) i zamiast niej umieściliśmy referencję do interfejsu Storage:

public interface Storage {
  void save(byte[] data);
}

Dzięki temu będziemy mogli w klasie NewsService używać dowolnej implementacji Storage. Inicjalizując klasę NewsService będziemy jej “wstrzykiwać” odpowiednią klasę implementującą interfejs Storage. Z praktycznego punktu widzenia na tym właśnie polega cała magia Dependency Injection!

Szczególnie warto zwrócić uwagę na kluczowy element DI. W klasie NewsService nie ma kodu, który by wyszukiwał implementację interfejsu Storage – gdybyśmy coś takiego umieścili, to zamiast DI używalibyśmy wzorca projektowego service locator, który jest obecnie nieco passe. NewsService oczekuje, że w czasie inicjalizacji ktoś mu poda odpowiednią implementację Storage. W naszym przypadku robi to klasa Client, której listing jest na samym dole wpisu.

Komunikację między klasami poprzez interfejsy demonstruje w sposób wyraźny poniższy diagram klas dla aplikacji:

Widać, że tak, jak chcieliśmy, NewsService zależy od innych klas wyłącznie poprzez interfejsy, nie przez implementacje.

Analogicznie DBStorage zależy od sterownika także poprzez interfejs Driver. W poprzedniej wersji aplikacji DBStorage był powiązany z konkretną wersją sterownika – DBDriver. Zobaczmy, jak wygląda kod, który implementuje zawartość diagramu.

public class DBStorage implements Storage{

  Driver driver;

  public DBStorage(Driver driver) {
    this.driver = driver;
  }

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

Sam interfejs Driver wygląda następująco:

public interface Driver {
  void openConnection();
  void closeConnection();
}

Konkretną implementacją sterownika jest u nas klasa SqlDbDriver:

public class SqlDbDriver implements Driver{

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

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

Pozostała jeszcze z poprzedniej wersji aplikacji byle jak zaimplementowana polityka uwierzytelniania. Teraz zrobimy to lepiej. W klasie NewsService, zgodnie z duchem DI, umieściliśmy odwołanie do interfejsu Authenticator:

public interface Authenticator {
  void authenticate() throws AuthException;
}

AuthException jest wyjątkiem czasu wykonywania:

public class AuthException extends RuntimeException{

  public AuthException(Throwable cause) {
    super(cause);
  }

  public AuthException(String message, Throwable cause) {
    super(message, cause);
  }

  public AuthException(String message) {
    super(message);
  }

  public AuthException() {
  }
}

W naszym kodzie używamy konkretnej implementacji uwierzytelniania:

public class UsernamePassAuthenticator implements Authenticator{
  private String uname;
  private String pass;

  public UsernamePassAuthenticator() {
  }

  public String getPass() {
    return pass;
  }

  public void setPass(String pass) {
    this.pass = pass;
  }

  public String getUname() {
    return uname;
  }

  public void setUname(String uname) {
    this.uname = uname;
  }

  public UsernamePassAuthenticator(String uname, String pass) {
    this.uname = uname;
    this.pass = pass;
  }

  /**
   * Username & password authenticator: username must be the same as
   * password - do not use it in production system ;)
   */
  public void authenticate() {
    if(!uname.equals(pass)){
      throw new AuthException("Authorization failed");
    }
  }
}

No i wreszcie nagroda za nasze wysiłki, czyli klasa kliencka:

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");
  }
}

Widzimy, że przed użyciem NewsService musimy go skonfigurować, czyli “wstrzyknąć” mu obiekty klas, które są potrzebne mu do działania.

Na koniec ćwiczenie dla szanownego czytelnika. W końcu czasem warto się sprawdzić. Czy teraz już nasza aplikacja na prawdę wygląda tak, jak trzeba? Na pewno? Czy może gdzieś jeszcze coś nie gra tak jak trzeba? Może gdzieś oszukałem? Jakiś mały problemik, architektoniczna niedoskonałość?

???

Jeżeli ktoś poczuł ducha DI, to pewnie od razu zorientował się, gdzie jeszcze tkwi problem. W klasie NewsService nadal tkwi ukryta zależność od klasy konkretnej zamiast interfejsu – w metodzie login klasy NewsService jest robione rzutowanie na klasę konkretną UsernamePassAuthenticator.

Zależność ta jest o tyle nieprzyjemna, że można ją na pierwszy rzut oka przeoczyć, w szczególności nie widać jej na diagramie UML-owym.

Warto się pozbyć się tego niezbyt eleganckiego kodu, świadczy on tylko o tym, że źle zaplanowaliśmy odpowiedzialność klasy NewsService. Niby dlaczego nagle ma ona zajmować się logowaniem, skoro może to zrobić Authenticator. Metoda login jest zwyczajnie zbędna.

To prowadzi nas z kolei do następnego pytania, na ile łatwo jest błędnie zaprojektować architekturę aplikacji, gdy zdecydujemy się używać wstrzykiwania zależności? Zajmiemy się tym problemem w trzeciej części cyklu.

Wreszcie dociekliwy czytelnik może zacząć się zastanawiać, jak będzie wyglądało to wstrzykiwanie zależności, jeżeli będziemy często używać NewsService – w końcu za każdym razem będziemy musieli mu wstrzykiwać te potrzebne klasy, co oznacza pisanie w kółko tego samego kodu. Czy nie lepiej jest użyć jednak jakiego wzorca factory czy service locator, żeby jednak NewsService sam sobie znalazł potrzebne klasy. Z tym problemem można sobie także poradzić najłatwiej przy użyciu kontenera Dependency Injection, takiego jak Spring, PicoContainer czy Guice. Temu będzie poświęcony czwarty wpis z serii 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.

Wstęp
Swing Application Framework jest szkieletem aplikacyjnym, który ma uprościć tworzenie aplikacji desktopowych w Java Swing. SAF z założenia ma być rozwiązaniem prostym, rozwiązującym podstawowe problemy, na jakie napotykamy się tworząc programy z interfejsem użytkownika w Javie.

Czym więc zajmuje się SAF?

• Cyklem życia aplikacji od jej uruchomienia po zamknięcie
• Zarządzaniem zasobami: łańcuchami znaków, kolorami, ikonami, czcionkami itp. rzeczami, które występują w typowej aplikacji. Oczywiście wszystkie zasoby mogą być internacjonalizowane/lokalizowane.
• Obsługą zdarzeń (co ma się stać, gdy użytkownik naciśnie przycisk X). W szczególności SAF upraszcza znacząco obsługę długotrwałych zdarzeń, które powinny wykonywać się w wątkach roboczych, a nie głównym
• Pamiętaniem stanu aplikacji. Po zamknięciu aplikacji pamięta ona jaki był stan interfejsu użytkownika (rozmiar okien, ich położenie) przed zamknięciem.

Żeby nie przedłużać wstępu przejdźmy do rzeczy, czyli przyjrzyjmy się przykładowej aplikacji Szukacz. Szukacz jest kulawą i ubogą namiastką grep-a napisaną w Javie, ma za to graficzny interfejs użytkownika.

Aplikacja jest skonstruowana inaczej niż w większości tutoriali Swing Application Framework, które można znaleźć w Internecie. Problem z umieszczonymi tam przykładami jest taki, że w rzeczywistej sytuacji są one mało użyteczne. Przykłady te dzielą się na dwie grupy:

1. aplikacje wyklikane od początku do końca w środowisku NetBeans, korzystające z kreatorów kodu tam dostępnych
2. aplikacje napisane całkowicie ręcznie, włącznie z elementami GUI

Tak na prawdę żadna z tych sytuacji nie jest typowa.

Ad. 1. Nie każdy musi chcieć używać NetBeansa (fakt, jest bardzo dobry jeśli chodzi o tworzenie GUI), a nawet jeżeli używamy go, to istnieje duża szansa, że mamy już napisany jakiś spory kawał kodu, który nie używa SAF i chcielibyśmy jakoś gładko istniejący kod zintegrować z tym frameworkiem.

Ad. 2. Jeśli nie jesteśmy maniakalnymi zwolennikami ręcznego dziergania kodu GUI, co zazwyczaj kończy się mniejszą lub większą katastrofą połączoną z gromami rzucanymi na Swinga i Javę w ogóle, to pewnie chcemy użyć jakiegoś wizulanego narzędzi, które pozwoli nam wyklikać strukturę GUI. Narzędzie to na bank nie słyszało jeszcze o SAF, a my chcemy sobie klikać interfejs użytkownika i jednocześnie łatwo go zintegrować z SAF.

Tak więc chcę pokazać, jak tworzyć sobie GUI takim sposobem, jak nam się podoba i móc go w każdej chwili zintegrować z SAF. Zatem do dzieła.

Logika “biznesowa” aplikacji
Zacznijmy od bardzo szybkiego spojrzenia na klasę Grep.java, która zajmuje się wyszukiwaniem podanego wyrażenie regularnego w plikach. Inicjalizujemy ją podając wyrażenie regularne, które kompilujemy ze względów wydajnościowych do obiektu java.util.regex.Pattern. Całą pracę wykonuje metoda void searchInFiles(File), która złośliwie nie zwraca wyników wyszukiwania. Możemy je otrzymać w formie miłej ludzkiemu oku metodą String getFormatedSearchResults(), a w formie miłej programistą dzięki metodzie Map<String, Map<Integer, String>> getSearchResults(). Zresztą kod mówi sam za siebie.

SAF – cykl życia aplikacji
Zajmiemy się teraz podstawowym kawałkiem SAF, czyli główną klasą aplikacji. Musi ona dziedziczyć po klasie Application lub SingleFrameApplication frameworka. Klasa SingleFrameApplication daje nam kilka dodatkowych usług oraz gotową instancję klasy reprezentującej okno w Swingu, czyli JFrame. Z powodów opisanych powyżej będziemy jednak samodzielnie tworzyć okno aplikacji – chcemy używać SAF, ale nie chcemy, żeby nam się on w aplikacji za bardzo panoszył. Klasa Application jest abstrakcyjna, dziedzicząc po niej musimy zaimplementować samodzielnie metodę void startup(), za chwilę się nią zajmiemy.

Popatrzmy na listing klasy MainApp.java.

package pl.xoft.saf.finder.ui;

import java.awt.Component;
import java.util.EventObject;
import javax.swing.JOptionPane;
import org.jdesktop.application.*;

public class MainApp extends SingleFrameApplication{
  ResourceMap resource;
  ApplicationContext ctxt;

  @Override
  protected void startup() {
    FrameView view = new MainViewFrame(this);
    view.setFrame(new MainFrame());
    show(view);

    addExitListener(new ExitListener() {
      public boolean canExit(EventObject e) {
        Object[] options = {resource.getString("label.yes"),
            resource.getString("label.no")};

        Object source = (e != null) ? e.getSource() : null;
        Component owner =
            (source instanceof Component) ?
                (Component)source : null;

        boolean mayExit = JOptionPane.showOptionDialog(
            owner,
            resource.getString("label.exit"),
            resource.getString("Application.name"),
            JOptionPane.YES_NO_OPTION,
            JOptionPane.QUESTION_MESSAGE,
            null,
            options,
            options[1]) == JOptionPane.YES_OPTION;

        return mayExit;
      }
      public void willExit(EventObject event) {
        //do nothing
      }
    });
  }

  @Override
  protected void initialize(String[] args) {
    System.out.println("Inicjalizacja... ");
    this.ctxt = getContext();
    ResourceManager mgr = ctxt.getResourceManager();
    resource = mgr.getResourceMap(MainApp.class);
  }

  @Override
  protected void shutdown() {
    System.out.println("Koniec pracy!! Czyścimy");
  }

  public static void main(String[] args) {
    Application.launch(MainApp.class, args);
  }
}

Żeby było inaczej niż zwykle, zacznijmy od końca, czyli metody main(String[]), przy pomocy metody Application.launch(Application) uruchamiamy całą aplikację. Metoda ta jest bardzo wygodna dla nas, bo nie musimy pamiętać o inicjalizacji GUI z poziomu odpowiedniego wątku, Event dispatching thread (EDT). Zróbmy w tym miejscu mały skok w bok, żeby wyjaśnić sobie terminologię no i żeby osoby mniej obyte z tematem wiedziały w czym rzecz.

Trzeba pamiętać, że typowa aplikacja Swingowa potrzebuje co najmniej trzech wątków:

1. głównego, który powinien tylko uruchomić aplikację,
2. Event dispatching thread, w którym, i tylko w którym można tworzyć i modyfikować komponenty interfejsu użytkownika,
3. wątku lub wątków roboczych, które wykonują wszystkie dłużej trwające zadania – nie chcemy ich wykonywać w EDT, żeby nie blokować interfejsu użytkownika.

Pierwszym często popełnianym błędem jest tworzenie GUI z poziomu wątku głównego, a nie EDT, często to nie powoduje problemów, ale zdarza się, że pojawiają się przykre i trudne do wykrycia błędy.

Metoda lanuch() powoduje rozpoczęcie wywołań kolejnych metod odpowiedzialnych za obsługę cyklu życia aplikacji, możemy przesłonić tylko te, które chcemy za wyjątkiem void startup().

• Metoda void initialize(String[]). Możemy w niej wykonać różnego rodzaju czynności inicjalizacyjne, które są potrzebne, w szczególności, jeśli trzeba je wykonać przed konstrukcją interfejsu użytkownika
• Metodę void startup() musimy przesłonić obowiązkowo: w tej metodzie inicjalizujemy tworzenie GUI. W metodzie tej tworzymy instancję klasy FrameView, która jest mostem pomiędzy SAF, a oknem aplikacji MainFrame. Potencjalnie MainFrame nie musi nic wiedzieć o SAF, dzięki czemu mamy dużą swobodę pracy z nią – nie jesteśmy uzależnieni od SAF, w każdej chwili możemy używać tych jego elementów, które chcemy.
• Metody void ready() nie ma na listingu, przesłaniamy ją wtedy, gdy potrzebne są jakieś czynności inicjalizacyjne po utworzeniu GUI – zazwyczaj chcemy jak najszybciej pokazać użytkownikowi interfejs aplikacji, a gdy on się jemu z podziwem przygląda możemy spokojnie dokończyć inicjalizację.
• Metoda void exit() kończy działanie aplikacji. Odbywa się to w ten sposób, że jeśli z poziomu aplikacji wywołane jest zdarzenie żądające zakończenia pracy (np. klikniemy przycisk “z krzyżykiem” okienka), to przejmowane jest ono przez klasę ExitListener-a, która sprawdza, czy wolno zakończyć działanie aplikacji. W naszym przypadku w metodzie startup() dodajemy ExitListener-a, który wyświetla okno dialogowe z pytaniem, czy możemy kończyć pracę.
• Metoda void shutdown(). Gdy zapadnie decyzja, że możemy kończyć ostatnią rzeczą jaka jest robiona jest wywołanie tej metody; możemy tam posprzątać po sobie lub zrobić cokolwiek, co ma być ostatnią rzeczą robioną przez nasz program.

Widzimy więc, że SAF automatyzuje i standaryzuje typowe elementy, które aplikacja powinna mieć: prawidłową inicjalizację i zakończenie działania.

Zarządzanie zasobami
Kolejnym elementem, który daje nam SAF jest zarządzanie zasobami. Dotyczy to wszystkich zasobów: napisów na etykietach, przyciskach, itp., ikon, używanych czcionek. W jaki sposób to się odbywa? Zasoby dzielą się na globalne i lokalne.

Zasoby globalne są umieszczone w pliku GlownaKlasaAplikacji.properties, który musi się znajdować w pakiecie nazwa.pakietu.resources, przy założeniu, że klasa GlownaKlasaAplikacji znajduje się w pakiecie nazwa.pakietu. W naszym przypadku zasoby globalne znajdziemy w pliku MainApp.properties i dla języka angielskiego w MainApp_en_US.properties. Oba pliki są w pakiecie pl.xoft.saf.finder.ui.resources.

Zasoby lokalne są przechowywane z tą samą konwencją co powyżej – każda klasa ma swój plik z zasobami umieszczony w pliku properties o nazwie takiej samej jak klasa.

Do zasobów dostajemy się tak jak to demonstruje listing klasy MainApp. W metodzie initialize(String[]) tworzymy uchwyt do bardzo użytecznej klasy, ApplicationContext (linia 49.), reprezentującej środowisko działania aplikacji. Następnie z kontekstu aplikacji wyciągamy klasę zarządzającą zasobami: ResourceManager. W klasie MainApp zasobów używamy przy tworzeniu okna dialogowego, które pojawia się, gdy ktoś chce zamknąć aplikację (linie 30 i 31).

Bardzo użyteczną cechą SAF jest automatyczna konwersja niektórych zasobów na klasy Java. Obejrzymy sobie fragment klasy MainFrame.html, w którym do aplikacji dodajemy element menu pozwalający zwiększyć wielkość czcionki.

        jMenuItem3.setAction(actionMap.get("makeLarger"));
        jMenuItem3.setAccelerator(KeyStroke.getKeyStroke(KeyEvent.VK_PAGE_UP, InputEvent.ALT_MASK | InputEvent.CTRL_MASK));
        jMenuItem3.setIcon(resourceMap.getIcon("jMenuItem3.icon"));
        jMenuItem3.setText(resourceMap.getString("jMenuItem3.text"));
        jMenuItem3.setName("jMenuItem3");
        jMenu2.add(jMenuItem3);

Aby menu było czytelniejsze jest tam umieszczona odpowiednia ikona. Bez SAF sami byśmy musieli z łańcuch znaków wyprodukować obiekt klasy ImageIcon, a tutaj wystarczy, że użyjemy metody ResourceMap.getIcon(String). Podobnie konwertowane są z łańcuchów znaków definicje czcionek i kolory. Niby drobne udogodnienie, ale jeśli dołożymy do tego internacjonalizację i pomnożymy wszystko przez 500 wystąpień w dużej aplikacji, to okaże się, że jednak trochę rękę oszczędziliśmy.

Akcje – obsługa zdarzeń
Wreszcie dochodzimy do najciekawszego elementy SAF, uproszczonego definiowania akcji. W Swingu jeśli chcemy, żeby jakiś komponent oprócz siedzenia w okienku mógł zrobić coś pożytecznego, musieliśmy dodać do niego nasłuchiwacza zdarzeń (ActionListener lub innego) a następnie tegoż nasłuchiwacza zaimplementować jako osobną klasę. Często robi się to wykorzystując klasę wewnętrzną.

SAF całą sprawę bardzo upraszcza, po prostu tworzymy metodę, oznaczamy ją metadaną @Action i dodajemy informację o tym, że pojawiła się obsługa zdarzenia do mapy akcji.

Popatrzmy na poniższy fragment kodu, wzięty z klasy MainPane.java:

//fragmenty klasy MainPane
public class MainPane extends javax.swing.JPanel {

  File f = null;

  public MainPane() {
    initComponents();
  }

  //w metodzie pozostawiona jest tylko inicjalizacja interesujących nas w tej chwili komponentów
  private void initComponents() {
    jTextArea1 = new javax.swing.JTextArea();
    jButton1 = new javax.swing.JButton();
    jTextField2 = new javax.swing.JTextField();

    jTextArea1.setColumns(20);
    jTextArea1.setEditable(false);
    jTextArea1.setFont(resourceMap.getFont("jTextArea1.font"));
    jTextArea1.setRows(5);
    jTextArea1.setName("jTextArea1");

    ActionMap actionMap = Application.getInstance(MainApp.class).getContext().getActionMap(MainPane.class, this);
    jButton1.setAction(actionMap.get("search"));
    jButton1.setText(resourceMap.getString("jButton1.text"));
    jButton1.setName("jButton1"); 

    jTextField1.setEditable(false);
    jTextField1.setText(resourceMap.getString("jTextField1.text"));
    jTextField1.setName("jTextField1");
  }

  @Action
  public void search() {
    jTextArea1.setText("");
    Grep g = new Grep(jTextField2.getText());
    try {
      if(f != null)
        g.searchInFiles(f);
    } catch (FileNotFoundException ex) {
      Logger.getLogger(MainPane.class.getName()).log(Level.SEVERE, null, ex);
    } catch (IOException ex) {
      Logger.getLogger(MainPane.class.getName()).log(Level.SEVERE, null, ex);
    }
    getJTextArea1().setText(g.getFormatedSearchResults());
  }
}

Interesuje nas wyłącznie obsługa przycisku “Szukaj”, dlatego cały kod służący do innych celów został usunięty z powyższego listingu. W linii 32. zaczyna się metoda search, oznaczamy ją metadaną @Action, żeby zarejestrować ją jako akcję. Pozostaje jeszcze powiązać odpowiedni przycisk (JButton1) z tę akcją. Robimy to w linii 23., wykorzystując klasę javax.swing.ActionMap.

Warto zwrócić uwagę na to, że możemy się odwoływać do akcji zdefiniowanych w innych klasach, przekazując odpowiedni obiekt do metody ApplicationContext.getActionMap(Class, Object) – jest to bardzo wygodne, gdyż raz zdefiniowaną akcję można wykorzystywać w całej aplikacji.

Pewnie najwygodniejszy byłby tutaj mechanizm wstrzykiwania zależności (ang. dependency injection), ale SAF ma być prosty, więc przynajmniej w obecnej wersji robimy to wyszukując odpowiednią klasę i metodę z kontekstu aplikacji.

Opisana implementacja funkcjonalności wyszukiwania jest bardzo prosta w implementacji, ma jednakże jedną dosyć zasadniczą wadę: jeżeli wyszukiwanie trwa dłużej, to blokuje ono interfejs użytkownika, w szczególności nie ma możliwości przerwania wyszukiwania. Dlaczego tak się dzieje jest jasne: długotrwałe zadanie wykonujemy w wątku EDT odpowiedzialnym za rysowanie interfesju użytkownika.

Musimy zatem uruchomić wyszukiwanie w osobnym wątku. Brzmi to dość prosto, ale w praktyce jest uciążliwe, gdyż trzeba zsynchronizować działanie wątku szukającego z wątkiem EDT. Dotychczas najwygodniejszym rozwiązaniem było wykorzystanie klasy narzędziowej SwingWorker [javadoc, przykład wykorzystania]. Podobne podejście stosuje SAF, tyle, że użycie analogicznego mechanizmu jest prostsze niż w przypadku SwingWorker-a.

Przyjrzymy się jeszcze raz klasie MainPane.java, tyle, że innemu jej fragmentowi

//fragmenty klasy MainPane
public class MainPane extends javax.swing.JPanel {

  File f = null;

  public MainPane() {
    initComponents();
  }
   //w metodzie pozostawiona jest tylko inicjalizacja interesujących nas w tej chwili komponentów
  private void initComponents() {
    ActionMap actionMap = Application.getInstance(MainApp.class).getContext().getActionMap(MainPane.class, this);

    jButton2.setAction(actionMap.get("searchNoBlocking"));
    jButton2.setText(resourceMap.getString("jButton2.text"));
    jButton2.setName("jButton2");

    jTextField2.setText(resourceMap.getString("jTextField2.text"));
    jTextField2.setName("jTextField2");

    jButton4.setAction(actionMap.get("cancel"));
    jButton4.setText(resourceMap.getString("jButton4.text"));
    jButton4.setName("jButton4");
  }

  @Action(block=Task.BlockingScope.COMPONENT)
  public Task searchNoBlocking() {
    searchTask = new SearchNoBlockingTask(Application.getInstance(MainApp.class));
    return searchTask;
  }

  private class SearchNoBlockingTask extends Task<String, Void> {
    StringBuilder str = null;
    Grep g = null;

    SearchNoBlockingTask(Application app) {
      super(app);
      jTextArea1.setText("");
      g = new Grep((jTextField2.getText()));
    }

    protected String doInBackground()  {
      try {
        if(f != null )
           g.searchInFiles(f);
      } catch (FileNotFoundException ex) {
        Logger.getLogger(MainPane.class.getName()).log(Level.SEVERE, null, ex);
      } catch (IOException ex) {
        Logger.getLogger(MainPane.class.getName()).log(Level.SEVERE, null, ex);
      }
      return g.getFormatedSearchResults();
    }
    protected void succeeded(String result) {
      getJTextArea1().setText(result);
    }
  }

  @Action
  public void cancel() {
    if(searchTask != null)
      searchTask.cancel(true);
  }
}

Tak jak wcześnie, do komponentu, w tym przypadku przycisku przypisujemy akcję, która tym razem nazywa się searchNoBlocking (linia 13.), inaczej wygląda za to implementacja wyszukiwania. Metoda obsługująca wyszukiwanie zwraca tym razem obiekt typu Task, którego instancję musimy utworzyć w metodzie (linia 25.).

Oczywiście nikt nam nie da gotowej klasy Task, także trzeba ją samodzielnie utworzyć, przesłaniając odpowiednie metody – właśnie to jest naszym celem. Nasza implementacja Task nazywa się SearchNoBlockingTask (linia 31.) i przesłaniamy w niej trzy metody:

• konstruktor, w którym inicjalizujemy potrzebne obiekty, warto zwrócić uwagę na to, że możemy w nim modyfikować stan GUI
• doInBackground(), która jest odpowiedzialna za uruchomienie wyszukiwania – ta metoda działa w osobnym wątku, nie blokuje zatem interfejsu użytkownika, nie wolno w tej metodzie odwoływać się w związku z tym do elementów GUI. Metoda ta jest automatycznie uruchomiana, gdy tworzymy instancję klasy SearchNoBlockingTask.
• succeeded, która jest wywoływana jak tylko skończy się działanie metody doInBackground() – w tej metodzie możemy zaktualizować interfejs użytkownika przy pomocy danych uzyskanych z metody doInBackground(). Metoda ta jest oczywiście uruchomiona w wątku EDT, dlatego może modyfikować GUI.

Klasa SearchNoBlockingTask ma jeszcze inne użyteczne metody, z jednej z nich korzystamy w metodzie cancel, umieszczonej na samym końcu listingu, przerywa ona wyszukiwanie po kliknięciu w odpowiedni przycisk.

Często się zdarza, że chcemy jednak zablokować jakąś część interfejsu użytkownika w czasie trwania długotrwałej operacji, możemy to zrobić ręcznie, w metodach klasy SearchNoBlockingTask, lub przekazując w parametrze metadanej @Action informację o tym, co chcemy blokować, w powyższym przykładzie blokujemy komponent, który spowodował rozpoczęcie wyszukiwania, czyli odpowiedni przycisk. Uchroni to naszą aplikację przed wielokrotnym jego naciśnięciem przez użytkownika.

Co jeszcze potrafi SAF
Jest jeszcze kilka rzeczy, o których warto wspomnieć. SAF ułatwia tworzenie bardzo często pożądanej funkcjonalności, czyli paska postępu. SAF zapamiętuje także automatycznie stan GUI – wielkość i położenie okien (akurat w moim przykładzie to nie działa, gdyż jest on skonstruowany nie do końca zgodnie z duchem SAF)

Dodatkowe informacje

• Strona projektu
• Wywiad z Hansem Mullerem, twórcą SAF A Framework for Swing
• Wprowadzenie do tworzenia aplikacji SAF w NetBeans: Introduction to the Swing Application Framework
• Dwa ciekawe artykuły poświęcone programowaniu z użyciem SAF: Using the Swing Application Framework (JSR 296) i
  Swing Application Framework Hacks Unleashed For Smarty Pantses

Podsumowanie
Najważniejszy pytanie oczywiście brzmi, czy SAF się przyjmie. Niewątpliwie Swing potrzebuje tego typu rozwiązania, także coś tę pustkę wypełni i nie bardzo widać konkurencję na tym polu. Potrzebne jest też wsparcie narzędzi, na razie SAF wspiera tylko NetBeans i robi to całkiem dobrze, mimo kilku drobnych uciążliwości, jak na przykład notoryczne kasowanie nazwy komponentu, do którego dodajemy akcję. Zobaczymy, co się będzie działo na polu tworzenia interfejsu użytkownika, bo ewidentnie szykuje się mniejszy lub większy przełom.

Z jednej strony aplikacje “grubego klienta” przestają być wystarczające w niektórych zastosowaniach, z drugiej strony interfejs użytkownika, który można utworzyć przy pomocy HTML/CSS/JavaScript nawet jeśli wykorzystuje się AJAX jest daleki od tego, co byśmy chcieli dostać. Pytanie brzmi, jaka technologia będzie używana: może wraz z uproszczeniem instalacji Javy, która ma być wkrótce dostępna jako Java SE 6 Update 10 (zwany także 6uN) do łask wrócą applety, które z technologicznego punktu widzenia są bardzo skutecznym rozwiązaniem w wielu zastosowaniach, podobnie może stać sie z Java Web Start. Są też oczywiście twardzi konkurenci na tym polu: Adobe Flex i Adobe Air no i Silverlight od Microsoftu.

Uwaga: artykuł bazuje na dość wczesnej wersji SAF, która może się jeszcze zmieniać, także z czasem niektóre rzeczy mogą przestać działać, albo zacząć działać niepoprawnie.

Porównanie obu bibliotek można znaleźć na stronie JSF Matrix, ale niewiele z niego wynika, jak to zazwyczaj bywa ze statystykami w rodzaju “liczba dostępnych komponentów”.

Kto i co robi
Zacznijmy od krótkiego przedstawienia obu bibliotek.

RichFaces. Biblioteka była produktem firmy Exadel, która połączyła się, albo została kupiona przez JBoss-a, czyli RedHata. Ehh, ten świat wielkich korporacji… Biblioteka jest dostępna na licencji Open Source, zawiera ponad 50 różnych komponentów JSF.

ICEFaces jest robiona przez firmę ICESoft i też jest opensorsowa.

Zalety RichFaces i wady ICE Faces
Dużą zaletą RichFaces jest pod-biblioteka Ajax4JSF, która pozwala “zajaksować” dowolny komponent JSF. Jest to bardzo wygodne, jeżeli mamy już napisany kawałek aplikacji i chcemy gdzieniegdzie ją upiększyć ajaksowymi wodotryskami.

Kolejną przyjemną cechą RichFaces jest możliwość określenia zachowania komponentów tak, żeby niekoniecznie za każdym razem łączyły się z serwerem (Ajaxa im można wyłączyć, innymi słowy). Można na przykład utworzyć stronę z zakładkami w ten sposób, że wszystkie są od razu ładowane i przy ich zmianie nie jest potrzebny kontakt z serwerem. Oczywiście można także skonfigurować sobie zachowanie ajaksowe, czyli zakładki będą doładowywane dynamicznie.

ICEFaces czegoś takiego nie potrafi, jego komponenty zawsze kontaktują się z serwerem, co jest trochę głupie w przypadku dajmy na to komponentu kalendarza – można go przecież zrobić łatwo po stronie klienta, każdorazowy kontakt z serwerem jest w 95% przypadków zbędny. Swoją drogą to jakaś obsesja, większość komponentów kalendarzowych ludzie robią ajaksem, tak przynajmniej mówi jsfmatrix.net.

ICEFaces pozwala używać JSF 1.2, ale wymaga używania trybu zgodności ze specyfikacją JSF 1.1. Trochę lipa.
W web.xml trzeba deklarować użycie starej wersji JavaServelts

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

a w faces-config.xml:

<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN" "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">

Przez to nie możemy wykorzystać różnych fajnych rzeczy, które wniosło JSF 1.2.

Łatwiej jest testować aplikacje, które używają RichFaces, bo JSFUnit wspiera właśnie to rozwiązanie – nic w tym dziwnego, gdyż JSFUnita robi RedHat.

Zalety ICE Faces i wady RichFaces
Ok, wygląda na to, że RichFaces wygląda lepiej, ale parę rzeczy w ICE też mi przypadło do gustu. Przede wszystkim wygląd, komponenty są na prawdę dopracowane, wyglądają perfekcyjnie.

Druga rzecz, to sposób odświeżania strony JSF. ICE robią aktualizację wszystkich elementów ajaksowych na całej stronie, dzięki czemu nie musimy się martwić o synchronizację obsługi różnych żądań ajaksowych. W RichFaces trzeba to robić ręcznie, co ma swoje wady.

ICEFaces mają lepiej działającą obsługę ajaksa w trybie “push”, RichFaces też to potrafią, ale stosunkowo od niedawna, więc ciężko stwierdzić, na ile ich implementacja działa niezawodnie.

No i wreszcie na koniec ICEFaces dobrze integrują się nie tylko z Eclipse, ale także z NetBeansem (dla mnie to ważne, bo coraz częściej używam tego drugiego).

Decyzja?
Póki co, zdecydowanie RichFaces.