Listing 1. Definicja using w Scali

object Using{
    def using[A <: {def close(): Unit}, B](param: A)(f:A => B): B = {
       try{
          f(param)
       } finally {
          param.close();
       }
    }
}

I później użyć w kodzie:

Listing 2. Użycie using w Scali

using(statement.executeQuery("select * from dual")){ resultSet =>{
     // reszta kodu
  }
}

Taka konstrukcja przypomina żonę, która okazjonalnie zamknie deskę (o ile będzie w pobliżu czytaj mąż użyje using).
Generalnie w tym przypadku definiujemy funkcję, która jako parametr przyjmuje obiekt klasy, w której zdefiniowano metodę close() i dodatkowo przyjmuje jako drugi element coś, nazwane f co dokonuje transformacji A na B. To jest znany z Pythona tzw. “Duck Typing” (Jeżeli coś chodzi jak kaczka i kwacze jak kaczka to jest to kaczka – wnioskowanie typu na podstawie bebechów).

Jak widać konstrukcja jest fajna i przydatna. Zatem można by spróbować przenieść ją bezpośrednio do Javy (to też jest tresura małżeńska). Oczywiście jest to zabawka, której używanie w kodzie produkcyjnym jest średnio rozważne… ale niema ryzyka nie ma zabawy. Najwyżej się coś wywali.

Listing 3. Definicja using w Javie

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

/**
 * Emulator using ze Scali czy C#.
 *
 * @author bartlomiejk
 *
 */
public class Using {

	/**
	 * Wykonuje operacje z body poczym wywołuje close() z t.
	 *
	 * @param 
	 *            typ generyczny z metodą close()
	 * @param t
	 *            zasób.
	 * @param body
	 *            operacja do wykonania.
	 * @throws RuntimeException
	 *             w dwóch przypadkach:
	 *

	 *
Brak metody close().

	 *
Security Manager niepozwala na wywołanie metody close.

	 *             

	 */
	public static  void using(T t, Unit body) throws RuntimeException {
		Class tClass = t.getClass();
		try {
			Method method = tClass.getMethod("close");
			method.setAccessible(true);
			try {
				body.perform(t);
			} finally {
				method.invoke(t);
			}
		} catch (SecurityException e) {
			throw new RuntimeException(e);
		} catch (NoSuchMethodException e) {
			throw new RuntimeException(e);
		} catch (IllegalArgumentException e) {
			e.printStackTrace();
		} catch (IllegalAccessException e) {
			e.printStackTrace();
		} catch (InvocationTargetException e) {
			e.printStackTrace();
		}
	}

	/**
	 * Synchronizowana wersja {@link #using(Object, Unit)}. synchronizacja względem zasobu.
	 *
	 * @see Using#using(Object, Unit)
	 *
	 * @param 
	 *            typ generyczny z metodą close()
	 * @param t
	 *            zasób.
	 * @param body
	 *            operacja do wykonania.
	 * @throws RuntimeException
	 *             w dwóch przypadkach:
	 *

	 *
Brak metody close.

	 *
Security Manager niepozwala na wywołanie metody close.

	 *             

	 */
	public static  void s_using(T t, Unit body) {
		synchronized (t) {
			using(t, body);
		}
	}

	/**
	 * Interfejs jednostki kodu wywołanej w ramach try/finally.
	 *
	 * @author bartlomiejk
	 *
	 * @param 
	 *            typ generyczny wykorzystywanego zasobu.
	 */
	public interface Unit {
		/**
		 * Wywoływana jednostka kodu.
		 *
		 * @param t
		 *            zasób.
		 */
		public void perform(T t);
	}
}

Metoda using występuje też w synchronizowanej wersji s_using, a muteksem jest zasób. Do wykorzystania z zasobami wymagającymi synchronizacji np. plikami.

Listing 4. Użycie using w Javie

using(daoSupport.executeQuery(CACHE_SQL), new Unit() {
	@Override
	public void perform(ResultSet t) {
		try {
			while (t.next()) {
				//...
			}
		} catch (Exception e) {
			throw new RuntimeException(e);
		}
	}
});

To tyle. Raz jeszcze kod jest ciekawostkowy, niedopracowany i pewno coś będzie wywalał. Zatem używacie na własne ryzyko. Licencja beerware.

Dodaj do

Generalnie zarówno call jak i execution nie różnią się jeżeli chodzi o moment wywołania. Jeżeli zdefiniujemy, że mają być wkompilowane przed to zostaną wkompilowane przed. Jeżeli po to po. Kompilator zapewnia, że w danym przepływie sterowania aspekt będzie umieszczony w odpowiednim miejscu. Oczywiście przy założeniu, że nie ma tam jakiś dodatkowych aspektów. Różnica leży w tym gdzie kompilator umieszcza kod.

Położenie call

Jeżeli używamy call to kompilator umieści kod porady w miejscu gdzie wywoływana jest dana metoda. Czyli jeżeli metoda A.a woła metodę B.b to kod zostanie umieszczony w metodzie A.a.

Położenie execution

Jeżeli używamy execution to kompilator umieści kod w wywoływanej metodzie. Przykładowo jeżeli A.a woła B.b to kod zostanie umieszczony w B.b.

Gdzie jest to istotne

W praktyce jeżeli wrzucamy kod aspektowy do naszych klas to nie ma różnicy czy użyjemy call czy execution. Kompilator i tak musi przeorać cały kod źródłowy… no właśnie. Kod źródłowy… Jeżeli wasza metoda jest wywoływana przez jakaś zewnętrzną bibliotekę np. chcecie dodać kod aspektowy do testu oznaczonego @Test to użycie call skończy się komunikatem Xlint:adviceDidNotMatch. Kompilator nie doda waszej porady ponieważ nie pracuje na kodzie wywołującym metodę. Dotyczy to też sytuacji gdzie do wywołania metody używacie refleksji. W takim wypadku macie dwa wyjścia. Po pierwsze użyć execution, co jest prostsze, ale narusza wasz kod (przyjmuję tu pracę z weaveringiem w czasie kompilacji). Po drugie użyć call wraz z weaveringiem w czasie ładowania klas.

Dodaj do

Piątek, a zatem słuchamy Listy w Trójce. Przed nami ostatnia z zasad Jeff’a Bay’a

Nie używaj getterów/setterów/własności

Niewątpliwie jest to najbardziej obiektowa z zasad. By zrozumieć o co w niej chodzi porównajmy takie oto dwie klasy

Listing 1. klasa bardziej “obiektowa”

class Chłopiec{

	private String imię;

	private String nazwisko;

	private String wiek;

	public String getImię() {
		return imię;
	}

	public void setImię(String imię) {
		this.imię = imię;
	}

	public String getNazwisko() {
		return nazwisko;
	}

	public void setNazwisko(String nazwisko) {
		this.nazwisko = nazwisko;
	}

	public String getWiek() {
		return wiek;
	}

	public void setWiek(String wiek) {
		this.wiek = wiek;
	}

}

Listing 2. klasa mniej “obiektowa”

class Dziewczynka {

	public String imię;

	public String nazwisko;

	public String wiek;

}

Czym różnią się te dwie klasy?

Obiektowość to nie metody

Pomijając różne specyficzne elementy języka związane z współbieżną zmianą stanu obiektów tych klas to te dwa twory niczym się nie różnią. Mogę jednak założyć się, że jeżeli pokażemy je “nagie i bezbronne” to pierwsza z nich zostanie zakwalifikowana jako bardziej obiektowa. Druga będzie mniej obiektowa. Dlaczego? Jakoś tak się utarło, że o obiektowości decydują metody.
W Javie jest to szczególnie potęgowane przez specyfikację Java Beans:

Properties are always accessed via method calls on their owning object. For readable properties
there will be a getter method to read the property value. For writable properties there will be a
setter method to allow the property value to be updated.

Cóż… Ma to pewien cel i jest tu pewien pomysł, ale tylko gdy przyjrzymy się tej specyfikacji jako całości (szczególnie z obsługa zdarzeń i wzorcem obserwatora). Niestety jak to w życiu bywa, ktoś z całego dokumentu wyciągnął jeden fragment i tak oto znaleźliśmy się w życi.

Czym jest obiektowość?

Obiektowość to przede wszystkim enkapsulacja. Inaczej mówiąc obiekty nie powinny ujawniać swojego wnętrza, a jedynie udostępniać pewien interfejs, który będzie odwzorowywał operacje dokonywane przez obiekt. Oczywiście może się tak zdarzyć, że operacja polega na ustawieniu jakiejś wartości obiektu. Jednak są to specyficzne przypadki. W żadnym wypadku nie należy pozwalać na swobodną manipulację właściwościami obiektu.

Co zamiast?

Skoro nie powinniśmy mieć możliwości swobodnej manipulacji jak tworzyć i konfigurować obiekty? Z każdym z elementów zajmiemy się z osobna.

Settery

Generalnie obiekty powinny być niezmienne. Ma to wiele zalet. Najważniejszą jest możliwość swobodnego programowania współbieżnego bez obawy, że wątki wzajemnie pozmieniają sobie dane. W takim wypadku settery zostaną automatycznie wyrugowane przez mechanizmy języka wymuszające ustawienie pól w konstruktorze.
Jeżeli jednak z jakiegoś powodu nie możemy użyć pól finalnych to należy ustawić je z użyciem jakiegoś kontenera DI. Zazwyczaj mamy dostęp do tego typu bibliotek i nie ma problemów z ich wykorzystaniem.
Co jednak gdy z jakiś powodów kontener DI nie jest dostępny? W takim wypadku zostaje nam wykorzystanie wzorca fabryki wzbogaconego o użycie refleksji.

Właściwości

Unikamy sytuacji kiedy zachowanie obiektu zależy od właściwości. To właściwość powinna dostarczać odpowiedniego zachowania. Przykładowo w poprzedniej części mówiłem, że opakowane kolekcje powinny dostarczać metod “kontekstowych”. Podobnie w trzeciej części gdzie mowa była o opakowaniu typów prymitywnych wspominałem o możliwości zamknięcia w typie opakowującym pewnych prostych operacji np. walidacji czy operacji arytmetycznych.

Gettery

Najbardziej kłopotliwy element. Koniec końców zawsze musimy gdzieś pokazać uzyskaną wartość. Najprościej jest przesłonić toString. Nie zawsze się to da zrobić. O ile zadziała to w przypadku prostych obiektów to już obiekty złożone stanową duży problem. Pewnym rozwiązaniem może być użycie odpowiedniego prezentera, czyli wzorca MVP. Prezenter może dostać się do obiektu via refleksja względnie odpowiednio zinterpretować wyniki z metody toString. Wzorzec ten ma w tym przypadku wiele zalet. Jeżeli jednak chcemy zrobić coś małego to można użyć czegoś co roboczo nazywam obiektem “samopezentującym się”. W takim przypadku obiekt posiada metodę, do której można przekazać docelowe miejsce prezentacji np. strumień i tyle. Jest to rozwiązanie o tyle wygodne, że czasami chcemy ograniczyć możliwość prezentacji obiektu. W takim wypadku metoda pełni rolę swoistego “pasa cnoty” ponieważ ogranicza kanały prezentacji.

Podsumowanie

Uff… przebrnąłem. Nie było łatwo. Paweł Lipiński w komentarzu do siódmej części zwrócił uwagę, że są to przede wszystkim pewne heurystyki. W części zerowej wspomniałem, że zasady te są świetne jeżeli chcemy refaktoryzować kod. Są też doskonałym narzędziem do ćwiczenia. Zatem czy stosować zasady Jeff’a Bay’a? Moim zdaniem warto dążyć do kodu napisanego zgodnie z tymi zasadami. Ponieważ kod taki promuje przemyślane konstrukcje, pozwala na odnalezienie potencjalnie niebezpiecznych fragmentów i karkołomnych konstrukcji w architekturze oraz wymusza pisanie testów. Ja napisałem projekt zgodny z tymi zasadami mający około 1000 linii. Teraz czas byś usiadł i napisał swój projekt.

Dodaj do

Rzecz w tym, że mam kilka własnych walidatorów, które korzystają z danych pobranych z bazy. Dane sa pobierane raz i zapisywane w takim pseudo cache, który potrafi odpowiedzieć na różne pytania dotyczące poszczególnych banków (czy mają włączone pewne usługi, czy są aktywne itp.). Zatem chcąc przetestować to rozwiązanie należało by użyć mocka. Na tapetę trafia zatem Mockito i koleżanka Whendy, która będzie udawała nam bazę danych.

// offtopic:
koleżanka Whendy zawdzięcza swoje imię temu, że konfigurując mocka używamy metod when i then.
// koniec offtopicu

Szyba konfiguracja i dla mniejszych testów śmiga. Przy okazji chciałem sprawdzić jak to zagra w przypadku większego testu. Nadal bez bazy danych, ale już odpalając wszytko na raz. Wziąłem zatem dyżurny zestaw 100k transakcji testowych. Napisałem prosty test “profilujący” pod kątem czasu, odpaliłem i OutOfMemmoryError się stos skończył. Nosz… na razie bez przekleństw. Zaparzyłem świeżą kawę i dawaj sprawdzamy. Plik wejściowy ~41MB co daje jakieś ~70MB w obiektach. Do dyspozycji jest 256MB RAM dla JVM w TestNg. Hm… szybko dopinam Dupaprofiler dla pamięci i widzę, że wykłada się przy około ~40K obiektów. Na Twittera idą bluzgi w temacie JSR-303. Pól dnia walki i co się okazało?

Każdy mock ma dodatkowe featury

Generalnie każdy mock tworzony przy pomocy frameworku ma kilka fajnych fearturów. Jednym z nich jest zbieranie informacji o wywołaniach, argumentach przekazanych do obiektu itp. Te dane zżerają pamięć w zastraszającym tempie. Skończyło się na pseudoimpelentacji interfejsu. Działa tak samo jak mock, ale nie zbiera informacji o wywołaniach. Jeżeli zatem w trakcie testów kończy ci się pamięć to sprawdź czy twoje mocki nie są zbyt zasobożerne.
Jeżeli tak jest to sprawdź czy potrzebujesz informacji o wywołaniach. Jeżeli nie to wystarczy zamiast mocków z frameworku napisać własną pseudo implementację. Jeżeli potrzebujecie jednak pewnych informacji to nie pozostaje nic innego jak dołożyć pamięci.

Dodaj do

Gladius Noctis, a na blogu ósma z zasad Jeff’a Bay’a

Klasa której polem jest kolekcja nie powinna mieć żadnych innych pól (opakowywanie kolekcji w klasy specyficzne dla kontekstu wykorzystania)

Nazwa trochę długa, ale nie ważne. Powróćmy na chwilę do pierwszej części tego cyklu. Na koniec przykładu z tablicami mieliśmy tam następujący kod:

Listing 1. Kod z pierwszej części

package pl.koziolekweb.eowp1;

public class Array3DFiller {

	public static void main(String[] args) {
		int[][][] array3d = new int[3][3][3];
		fillArray(array3d);

		printArray(array3d);

	}

	private static int fill2dArray(int[][][] array3d, int current, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			current = fillRow(array3d, current, i, j);
		}
		return current;
	}

	private static int fillArray(int[][][] array3d) {
		int current = 0;
		for (int i = 0; i < array3d.length; i++) {
			current = fill2dArray(array3d, current, i);
		}
		return current;
	}

	private static int fillRow(int[][][] array3d, int current, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++, current++) {
			array3d[i][j][k] = current;
		}
		return current;
	}

	private static void print2dArray(int[][][] array3d, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			printRow(array3d, i, j);
			System.out.println();
		}
	}

	private static void printArray(int[][][] array3d) {
		for (int i = 0; i < array3d.length; i++) {
			print2dArray(array3d, i);
			System.out.println();
		}
	}

	private static void printRow(int[][][] array3d, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++) {
			System.out.print(String.format("%2s ", array3d[i][j][k]));
		}
	}

}

Przy tamtych założeniach było ok. Krawetko podał jeszcze zgrabniejszą wersję. Ja jednak zmienię tu wszystko.

Co robimy z kolekcjami?

Przede wszystkim iterujemy. Przeciskamy przez różne formy pętli w celu wykonania operacji na wszystkich elementach kolekcji. W Javie jest to dość upierdliwe. Za każdym razem należy napisać te klika linijek kodu by przepuścić daną kolekcję przez pętlę. W dodatku może okazać się, że coś skrewiliśmy albo nasz kod dostał się w niepowołane ręce, które wykonały kilka niefajnych operacji bezpośrednio na kolekcji.
W Scali jest trochę lepiej mamy metodę foreach, która opakowuje pętlę:

Listing 2. foreach w Scali

val x = 1 to 10
x foreach ($ => println($*$))

I już mamy kwadraty liczb od 1 do 10. W javie trzeba na to dwóch pętli.

Oczywiście jest tu ukryty mały "fakap" ponieważ zarówno metoda to jak i foreach maskują nam odpowiednie pętle. W przypadku to jest to jeszcze wzbogacone o lazy-init, ale to insza inszość.

Dlaczego opakowywać kolekcje?

Kod w Scali fajny jest. Dlatego warto stworzyć sobie podobne możliwości. W Javie nie jest to trudne generalnie poniższy kawałek kodu rzucił mi się kiedyś w oczy, ale skąd pochodzi ta koncepcja nie jestem wstanie powiedzieć.

Listing 3. foreach w Javie

interface Foreach {

	interface Action {
		void perform(T t);
	}

	abstract class ForeachImpl implements Foreach {

		private static class ArrayDelegate implements Foreach {

			private T[] array;

			public ArrayDelegate(T[] array) {
				this.array = array;
			}

			@Override
			public void foreach(Action action) {
				for (T t : array) {
					action.perform(t);
				}
			}
		}

		private static class Delegate extends ForeachImpl {

			public Delegate(Collection collection) {
				super(collection);
			}
		}

		public static  Foreach delegate(Collection collection) {
			return new Delegate(collection);
		}

		public static  Foreach delegate(D[] collection) {
			return new ArrayDelegate(collection);
		}

		private Collection collection;

		private ForeachImpl(Collection collection) {
			this.collection = collection;
		}

		@Override
		public void foreach(Action action) {
			for (T t : collection) {
				action.perform(t);
			}
		}
	}

	public void foreach(Action action);
}

Jest to trochę karkołomna konstrukcja w tej postaci, ale wiadomo o co chodzi. Odpowiednie zagłębienia służą tu odwaleniu roboty podobnej do tej jaką odwala scalac przy dodawaniu traita do klasy. Dla przypomnienia jeżeli trait nie zawiera implementacji to jest traktowany jak interfejs. Jeżeli zawiera implementacje to tworzone są klasy abstrakcyjne zawierające zaimplementowane metody i w klasie docelowej następuje delegacja zachowania do takiej wewnętrznej klasy. Tyle w skrócie zainteresowanych odsyłam do konsoli i polecenia javap.

Nasza klasy wystarczy, że zaimplementuje interfejs i wydeleguje obsługę metody do klasy Delegate. Już dużo mniej roboty później przy iterowaniu przez kolekcję wystarczy zaimplementować clou pętli czyli to co pomiędzy { i }. Można to też łatwo przetestować. Ba! Można implementację przerzucić na użytkownika API. Niech powie co robi z pojedynczym elementem kolekcji, a to jak będzie przechodził przez kolekcję to już nie jego sprawa. Tu dochodzimy do takiego modelu, który jest już blisko programowania funkcyjnego. Klient mówi CO i nie martwi się JAK.

Wypełniamy tablicę

Powróćmy do pierwszego kodu. W pierwszym kroku opakujmy tablicę jednowymiarową o zadanej ilości elementów w coś przyjaznego dla środowiska:

Listing 4. Opakowana tablica intów

class ArrayOfInt {

	private Integer array[];

	public ArrayOfInt(int size) {
		array = new Integer[size];
	}

	public int fill(final int start) {
		return fill(start, 1);
	}

	public int fill(final int start, final int step) {
		int next = start;
		for (int i = 0; i < array.length; i++) {
			array[i] = next;
			next += step;
		}
		return next;
	}

	public void print() {
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(Integer t) {
				System.out.print(String.format("%2s ", t));

			}
		});
	}

}

Ok, na razie nic groźnego. O ile inicjację tablicy i jej wypełnienie musimy przeprowadzić iterując z palucha to już wypisanie robimy za pomocą delegowania.
Teraz czas na tablicę dwu wymiarową. W tym przypadku musimy powiedzieć ile kolumn i ile rzędów chcemy mieć. Jednak czy aby na pewno? Opakowujemy w końcu kolekcję kolekcji... zatem...

Listing 5. Opakowana dwu wymiarowa tablica intów

class Array2dInt {

	private class Next {
		int next;
	}

	private ArrayOfInt array[];

	public Array2dInt(int rows, int cols) {
		array = new ArrayOfInt[rows];
		for (int i = 0; i < array.length; i++)
			array[i] = new ArrayOfInt(cols);
	}

	public int fill(final int start) {
		return fill(start, 1);
	}

	public int fill(final int start, final int step) {
		final Next next = new Next();
		next.next = start;
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(ArrayOfInt t) {
				next.next = t.fill(next.next, step);
			}
		});

		return next.next;
	}

	public void print() {
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(ArrayOfInt t) {
				t.print();
				System.out.println("");
			}
		});
	}
}

Whoa... inicjacja w konstruktorze nadal z palucha (tego nie przeskoczymy). Reszta przez delegaty. Tablica trójwymiarowa to już formalność.

Listing 5. Opakowana trójwymiarowa tablica intów

class Array3dInt {

	private class Next {
		int next;
	}

	private Array2dInt array[];

	public Array3dInt(int rows, int cols, int depth) {
		array = new Array2dInt[depth];
		for (int i = 0; i < array.length; i++)
			array[i] = new Array2dInt(rows, cols);
	}

	public int fill(final int start) {
		return fill(start, 1);
	}

	public int fill(final int start, final int step) {
		final Next next = new Next();
		next.next = start;
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(Array2dInt t) {
				next.next = t.fill(next.next, step);
			}
		});

		return next.next;
	}

	public void print() {
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(Array2dInt t) {
				t.print();
				System.out.println("");
			}
		});
	}
}

Całość można oczywiście ładnie rozdzielić na nieanonimowe klasy wewnętrzne (albo wyrzucić do osobnych klas o ograniczonej widoczności) czy uczynić generycznym. Cały kod jest, wbrew pozorom, prostszy i łatwiejszy w testowaniu.

Podsumowanie

Bardzo istotną rzeczą w takim podejściu do kodowania jest umiejętność rozdzielenia swojej osobowości na klienta i dostawcę. W przeciwnym wypadku możemy nieźle przestraszyć się ilością kodu.

Najistotniejszą cechą jest jednak ograniczenie klientowi pola manewru w pracy z kolekcją. Mając ograniczone API i pozbawiając go możliwości dowolnego manipulowania elementami możemy się zabezpieczyć przed nieprzyjemnymi sytuacjami jak chociażby usunięcie elementu z kolekcji (boli jak używasz JPA), głębokie klonowanie kolekcji albo nieskończonego iterowania.
Dodatkowo operacje biznesowe są jasno określone przez co zmniejsza się prawdopodobieństwo "hakierowania" i tworzenia obejść we właściwym kodzie biznesowym.

Gdzie warto używać

Przede wszystkim warto opakowywać kolekcje, które wychodzą z bazy danych/DAO. W ten sposób można ograniczyć manipulowanie obiektami w ramach kodu biznesowego. Wszelkie operacje związane ze zmianą stanu bazy będą dokonywane poprzez interfejs opakowanej kolekcji. Dzięki czemu można kontrolować kto co może. W takim układzie aplikacja nie widzi DAO jako takiego. Widzi tylko interfejs dostarczający pewne dane na których można wykonać ściśle określone operacje.
Po drugie MVP. W tym przypadku kolekcja staje się pomocnikiem dla prezentera. Można dzięki temu wprowadzić np. dodatkowe filtrowanie danych tuż przed ich wyświetleniem. To pozwala na stworzenie jednego prezentera, który będzie prezentował dane w zależności od potrzeb, ale będzie jednocześnie na tyle elastyczny by móc z niego skorzystać w wielu miejscach. Przykładowo kolekcja A przed wyświetleniem wymaga wycięcia części danych, których nie bardzo można pozbyć się na etapie pobierania z bazy. Jednocześnie kolekcja B nie ma tych danych już domyślnie. Obie mają metodę show przyjmującą jako parametr prezenter. Następnie w środku wywołują tylko wybrane metody prezentera.
Po trzecie filtry. W takim przypadku zamiast pozwolić iterować po kolekcji możemy udostępnić klientowi ileś tam predefiniowanych metod, które filtrują kolekcję w określony sposób. Tu mała uwaga. Szkoda, że w Javie nie ma eleganckich domknięć i trzeba stosować haki w stylu anonimowych klas.

Dodaj do

By ogarnąć DI należy napisać jeden projekt bez użycia słowa kluczowego new w kodzie biznesowym. Można go używać w provideach. Dozwolone jest też tworzenie prymitywów i Stringów “z palca”.

Dodaj do

Generalnie po ustawieniu pola chcemy wykonać pewne operacje.

Wstrzykiwanie via setter

W guice adnotujemy @Inject metodę (dowolna nazwa, widoczność itp.) i to wszystko. Problem polega na tym, że obiekt jest w stanie nieokreślonym. Raz, że jego tworzenie jeszcze trwa, a dwa, że nie mamy kontroli nad kolejnością wywoływania metod.

Wstrzykiwanie via pole + @PostConstruct

W tym przypadku w momencie gdy metoda/y oznaczone @PostConstruct są wywoływane mamy pewność, że obiekt jest już zainicjowany i spójny. Plusem jest tu też możliwość ukrycia implementacji (brak setterów, metoda może być niewidoczna). Nadal nie mamy kontroli nad kolejnością wywołań w przypadku wielu metod @PostConstruct, ale zazwyczaj jedna wystarczy by w niej wykonać określone akcje w zadanej kolejności.

Gdzie to jest ważne

Takie coś może okazać się bardzo istotne w momencie gdy robicie DI na elementach GUI. Większość silników UI ma to do siebie, że dodając komponenty robi to w kolejności wywołania metod. Jedynym wyjątkiem są siatki, gdzie można kontrolować położenie komponentu w przestrzeni. Trochę inaczej ma się to w przypadku managerów wyglądu typu Vertical/Horizontal. Tam istotna jest kolejność wywołania metody. Zatem jeżeli nie chcecie stopki na górze strony…

Dodaj do

Na razie mam dwie propozycje:

• Wstrzykiwanie parametryzowane.
• Wstrzykiwanie wspomagane.

Dodaj do

Już doszliście do siebie… to dobrze…

Słowo wstępne

Na spotkaniu WJUGa, na którym wraz z Wojtkiem Ebertowskim omawialiśmy Guice Paweł Szklarz zarzucił temat “Guice to ma a Spring nie” na przykładzie modułów prywatnych. Rzecz jest to o tyle ciekawa, że świetnie obrazuje podstawową różnicę pomiędzy Guice, a Springiem. Sposób konfiguracji.

Ogólnie rzecz ujmując. W springu wszystko co zostanie użyte w ramach taga bean jest przetwarzane tylko w kontekście tego taga. Jeżeli zatem macie dwa beany springowe implementujące ten sam interfejs i zależne od jakiegoś tam, ale identycznego, interfejsu w dwóch różnych implementacjach to możecie skonfigurować wszystko w osobnych tagach bean. Zależności uczynić anonimowymi (nie ustawiać id) i generalnie pozbyć się problemu. W Guice nie za bardzo idzie tak zrobić, ponieważ chcąc uzyskać jak najogólniejsze łączenie interfejsu z implementacją musimy takie mapowanie upublicznić. Powoduje to, że nie można dodać kolejnego identycznego mapowania.

Przykład z życia

Potrzebujemy w ramach aplikacji odwoływać się do dwóch identycznych baz danych. Te same mapowania, te same operacje, itd. tylko inne adresy. W Springu stworzylibyśmy klasę i skonfigurowali ja jako dwa niezależne beany, każdy w własną konfiguracją. W Guice taka sztuczka nie przejedzie ponieważ konfiguracja JpaPersistModule nie pozwala na wykorzystanie wielu jednostek utrwalania. Dodatkowo nie idzie tego skonfigurować. Z pomocą przychodzą tu moduły prywatne.

Moduł prywatny kto zacz

Moduł prywatny jest to specjalna implementacja modułu Guice, która w trakcie tworzenia w danym injectorze tworzy injector pochodny i do niego dowiązuje swoją konfigurację. W ten sposób konfiguracja jest niewidoczna w nadrzędnym injectorze, a tym samym można stworzyć wiele identycznych konfiguracji, które nie będą się wzajemnie widzieć. Można oczywiście pewne elementy konfiguracji upublicznić co pozwala na np. użycie dwóch identycznych jednostek utrwalania w ramach jednego projektu.

Przykładzik

Zadanie przepisać tabelę z jednej bazy do drugiej.

Na początek konfiguracja baz danych. Wykorzystuję tu dwie instancje HSQLDB umieszczone w pamięci. Jedyny problem z tym związany to konieczność dodania danych do źródła za pomocą DAO. Jak chcesz to przerzuć się na postgresa i wykorzystaj DBUnit.

Listing 1. konfiguracja baz – persistence.xml

org.hibernate.ejb.HibernatePersistence
		pl.koziolekweb.guice.SomeEntity









		
	

org.hibernate.ejb.HibernatePersistence
		pl.koziolekweb.guice.SomeEntity









		
	

Następnie interfejs DAO:

Listing 2. DAO

package pl.koziolekweb.guice;

import java.util.Collection;

public interface SomeEntityDao {

	void saveAll(Collection someEntities);

	Collection getAll();
}

Implementacja

Listing 3. implementacja DAO

package pl.koziolekweb.guice;

import java.util.Collection;

import javax.inject.Inject;
import javax.persistence.EntityManager;

import com.google.inject.persist.Transactional;

public class SomeEntityDaoImpl implements SomeEntityDao {

	@Inject
	private EntityManager em;

	@Transactional
	@Override
	public void saveAll(Collection someEntities) {
		for (SomeEntity se : someEntities)
			em.merge(se);
		em.flush();
	}

	@Transactional
	@Override
	public Collection getAll() {
		return em.createQuery("Select se From SomeEntity se", SomeEntity.class).getResultList();
	}

}

oraz nasza encja

Listing 4. SomeEntity

package pl.koziolekweb.guice;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.SequenceGenerator;

@Entity
public class SomeEntity {

	@SequenceGenerator(name = "Gen", sequenceName = "Seq")
	@GeneratedValue(generator = "Gen")
	@Id
	public Long id;

	public String name;

	public SomeEntity() {

	}

	public SomeEntity(String name) {
		this.name = name;
	}
}

Jak widać nie ma tu nic niezwykłego.

Aplikacja

Kolejnym elementem jest aplikacja przepisująca dane. Klasa posiada ona dwa pola reprezentujące dao powiązane z różnymi PU.

Listing 5. Wybitnie skomplikowana klasaApp

package pl.koziolekweb.guice;

import java.util.LinkedList;
import java.util.List;

import javax.inject.Inject;
import javax.inject.Named;

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

public class App {

	@Inject
	@Named("source")
	private SomeEntityDao source;

	@Inject
	@Named("target")
	private SomeEntityDao target;

	public static void main(String[] args) {
		Injector injector = Guice.createInjector(new MainModule());
		App instance = injector.getInstance(App.class);
		instance.prepare();
		instance.verify();
		instance.copy();
		instance.verify();
	}

	public void verify() {
		System.out.println(source.getAll().size());
		System.out.println(target.getAll().size());
	}

	public void copy() {
		target.saveAll(source.getAll());
	}

	public void prepare() {
		List data = new LinkedList();
		data.add(new SomeEntity("A"));
		data.add(new SomeEntity("B"));
		data.add(new SomeEntity("C"));
		source.saveAll(data);
	}

}

Jak widać instalujemy tylko jeden moduł – MainModule. Przyjrzyjmy się mu

Listing 6. główny moduł aplikacji

package pl.koziolekweb.guice;

import com.google.inject.AbstractModule;

public class MainModule extends AbstractModule {

	@Override
	protected void configure() {
		install(new DaoModule("source-pu", "source"));
		install(new DaoModule("target-pu", "target"));
	}

}

Nie ma tu nic nadzwyczajnego. Instalujemy dwa moduły DaoModule. Przyjrzyjmy się tej klasie (zaczyna się robić wpis ginekologiczno-pornograficzny wnikamy głębiej).

Listing 7. Moduł zarządzający DAO

package pl.koziolekweb.guice;

import com.google.inject.PrivateModule;
import com.google.inject.name.Names;
import com.google.inject.persist.jpa.JpaPersistModule;

public class DaoModule extends PrivateModule {

	private String jpaUnit;
	private String emMarker;

	public DaoModule(String jpaUnit, String emMarker) {
		super();
		this.jpaUnit = jpaUnit;
		this.emMarker = emMarker ;

	}

	@Override
	protected void configure() {
		install(new JpaPersistModule(jpaUnit));
		bind(DaoInitializer.class).asEagerSingleton();
		bind(SomeEntityDao.class).annotatedWith(Names.named(emMarker)).to(SomeEntityDaoImpl.class);
		expose(SomeEntityDao.class).annotatedWith(Names.named(emMarker));
	}

}

Tu zaczyna być ciekawie. Zanim omówię co i jak to dla porządku klasa DaoInitializer:

Listing 8. Klasa DaoInitializer

package pl.koziolekweb.guice;

import javax.inject.Inject;

import com.google.inject.persist.PersistService;

public class DaoInitializer {

	@Inject
	public DaoInitializer(PersistService service) {
		System.out.println(service.toString());
		service.start();
	}
}

ale co się dzieje

Na listingu 8 mamy sobie klasę – moduł guice, która zamiast AbstractModule rozszerza PrivateModule. W konstruktorze przyjmuje ona sobie dwa parametry. Pierwszy to nazwa PU z pliku konfiguracyjnego, a drugi to nazwa pod jaką będziemy udostępniać DAO. Generalnie mamy tu dość dużą swobodę. Można przyjąć, że pola trzymające DAO muszą mieć taką samą nazwę (w sensie adnotacji @Named) jak używany PU. Można dać opcję na własną adnotację. Można przyjąć, że nazwa podana w kodzie ma odpowiednik w xmlu z jakimś przedrostkiem, przyrostkiem, wrostkiem, wyrostkiem czy innym tego typu tworem (brak ci inwencji w nazewnictwie – sięgnij po podręcznik do dermatologii, na pewno coś znajdziesz).
Następnie jest sobie metoda configure, a w niej instalujemy w pierwszej kolejności moduł do obsługi JPA. Następnie tworzymy i inicjujemy (użycie asEagerSingleton) obiekt DaoInitializer, który uruchamia nam usługę JPA. Teraz możemy już powiązać interfejs i implementację DAO koniecznie wykorzystując tu informację, że pole jest adnotowane. Ostatnim akordem tej zabawy jest wywołanie metody expose, która udostępnia definicję naszej konfiguracji innym modułom (umieszcza ją w nadrzędnym injectorze). Co ważne wszystko co znajduje się w tym module jest odseparowane od świata. Zatem nie ma możliwości by nadpisać sobie konfigurację w innym module.

Uruchamiamy…

Listing 9. uruchomienie aplikacji

com.google.inject.persist.jpa.JpaPersistService@77158a
com.google.inject.persist.jpa.JpaPersistService@a7c45e
Hibernate:
    insert
    into
        SomeEntity
        (id, name)
    values
        (null, ?)
Hibernate:
    call identity()
Hibernate:
    insert
    into
        SomeEntity
        (id, name)
    values
        (null, ?)
Hibernate:
    call identity()
Hibernate:
    insert
    into
        SomeEntity
        (id, name)
    values
        (null, ?)
Hibernate:
    call identity()
Hibernate:
    select
        someentity0_.id as id0_,
        someentity0_.name as name0_
    from
        SomeEntity someentity0_
3
Hibernate:
    select
        someentity0_.id as id2_,
        someentity0_.name as name2_
    from
        SomeEntity someentity0_
0
Hibernate:
    select
        someentity0_.id as id0_,
        someentity0_.name as name0_
    from
        SomeEntity someentity0_
Hibernate:
    select
        someentity0_.id as id2_0_,
        someentity0_.name as name2_0_
    from
        SomeEntity someentity0_
    where
        someentity0_.id=?
Hibernate:
    insert
    into
        SomeEntity
        (id, name)
    values
        (null, ?)
Hibernate:
    call identity()
Hibernate:
    select
        someentity0_.id as id2_0_,
        someentity0_.name as name2_0_
    from
        SomeEntity someentity0_
    where
        someentity0_.id=?
Hibernate:
    insert
    into
        SomeEntity
        (id, name)
    values
        (null, ?)
Hibernate:
    call identity()
Hibernate:
    select
        someentity0_.id as id2_0_,
        someentity0_.name as name2_0_
    from
        SomeEntity someentity0_
    where
        someentity0_.id=?
Hibernate:
    insert
    into
        SomeEntity
        (id, name)
    values
        (null, ?)
Hibernate:
    call identity()
Hibernate:
    select
        someentity0_.id as id0_,
        someentity0_.name as name0_
    from
        SomeEntity someentity0_
3
Hibernate:
    select
        someentity0_.id as id2_,
        someentity0_.name as name2_
    from
        SomeEntity someentity0_
3

…i się cieszymy.

Podsumowanie

Prywatne moduły wprowadzają nam funkcjonalność, która nie jest spotykana w Springu. Jednocześnie należy zaznaczyć, że Spring reprezentuje zupełnie inne podejście do problemu konfiguracji i zakresów widoczności poszczególnych beanów. Tym samym nie można mówić o tym, które rozwiązanie jest lepsze. One są po prostu diametralnie różne.

Dodaj do

Uruchomienie:

Listing 1. uruchomienie konwertera

$> java -jar tod2mpg.zip -h

Ci, którzy cenią porządek mogą se zmienić rozszerzenie na jar. Licencja Beerware^W. Źródła wrzucę na githuba wieczorem.

// edit:

całość na Githubie:
git://github.com/Koziolek/tod2mpeg-converter.git

Swoją drogą proszę się nie przerazić trywialnością rozwiązania. Trochę się wkurzyłem jak odkryłem CZYM są pliki TOD

Dodaj do