Rodzaje porad

Porada jest to pojedyncza operacja wstawiana w odpowiedni punkt przecięcia. Generalnie istnieją trzy rodzaje porad (i ich zrozumienie jest naprawdę proste w porównaniu z definicjami punktów przecięcia). Pierwszy to znana nam już porada before. Wstawiana jest w kod przed wykonaniem danego działania. Po jej wykonaniu wykonywany jest kod punktu przecięcia.
Drugim rodzajem porad są porady after. Tu sprawy trochę się komplikują. Po pierwsze mogą wystąpić trzy podrodzaje porady. Pierwsze to zwykłe porady. Wykonane będą zawsze po kodzie punktu przecięcia. Jeżeli wysypie się on z jakimkolwiek błędem nasza porada zostanie wykonana i dopiero po niej zostanie wyrzucony błąd. Drugie to porady afterthrowing, które wykonają się wtedy i tylko wtedy, gdy kod punktu przecięcia wywali wyjątek. Kod porady wykona się przed zwróceniem wyjątku lub po, bo całość nie jest jakoś specjalnie synchronizowana. Trzeci rodzaj to porady afterreturning, które to wykonają się tylko wtedy gdy kod w punkcie przecięcia zakończy się prawidłowo. Poniżej przykładowy aspekt, który ilustruje działanie wszystkich tych dróg:

Listing 1. Porada typu after

package pl.koziolekweb.blog.aspectj;

import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.AfterThrowing;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class ErrorHandlerAspect {

	@Pointcut("execution(* NKWD.*(..))")
	public void handleError(){}

	@After("handleError()")
	public void handleErrorAdvice(){
		System.out.println("Metoda wyrzuca błąd");
	}

	@AfterThrowing(value = "handleError()", throwing = "runtimeException")
	public void handleErrorThrowsAdvice(RuntimeException runtimeException) {
		System.out.println("Metoda wyrzuciła błąd: "
				+ runtimeException.getLocalizedMessage());
	}

	@AfterReturning("handleError()")
	public void handleErrorNotThrowAdvice(){
		System.out.println("Metoda nie wyrzuciła błędu");
	}
}

Pobaw się z dodawaniem deklaracji wyjątku do klasy NKWD i zobacz co się stanie.
Trzeci rodzaj porad to porady around. Są one szczególnie przydatne wszędzie tam, gdzie zazwyczaj do wykonywania jakiś czynności wykorzystujemy wzorzec metody szablonowej. Jednocześnie szablon nie realizuje samego algorytmu, a jedynie pozwala na wykonanie czynności takich jak logowanie startu i końca akcji, blokowanie obiektów (ukochany ReadWriteLock), rozpoczynanie i kończenie transakcji, proste profilowanie. Kolejnym wzorcem, który można zastąpić tym rodzajem porady jest dekorator. Bardzo dobrym pomysłem jest dekorowanie obiektów w sposób przezroczysty dla klienta. Niestety klient musi w takim wypadku korzystać z interfejsu do komunikacji z obiektem (co jest bardzo fajne) i uzyskiwać obiekty z jakiejś fabryki (co jest upierdliwe zarówno dla klienta jak i programisty). Oczywiście jest Spring, EJB3.x czy Pico, ale jakoś nie widzę sensu ich użycia tylko dla jednego małego dekoratora (pamiętaj, używanie frameworków powoduje gwałtowne rozrastanie się kodu wynikowego). Zresztą nie zawsze da się użyć frameworku.
Problemem z tym rodzajem porady jest konieczność wstawienia jakiegoś elementu, który pozwalał by na określenie jaki kod ma być wykonany przed, a jaki po wykonaniu kodu punktu przecięcia. AspectJ dostarcza odpowiedniego pseudo słowa kluczowego proceed(). Jest to pseudo słowo kluczowe ponieważ w praktyce jest to metoda
Napiszmy profiler, który będzie sprawdzał ile czasu zajmuje użytkownikowi wpisanie hasła. Przy okazji mały refaktoring kodu NKWD:

Listing 2. Nowa wersja NKWD

package pl.koziolekweb.blog.aspectj;

import java.util.Scanner;

public class NKWD {

	private boolean isAuth = false;

	public void auth(){
		if (isAuth) {
			return;
		} else {
			String password = readPassword();
			isAuth = validatePassword(password);
			if (!isAuth) {
				throw new RuntimeException("Wypad na Łubiankę");
			}
		}
	}

	private String readPassword() {
		System.out.print("podaj hasło: ");
		Scanner scanner = new Scanner(System.in);
		String password = scanner.next();
		return password;
	}

	private boolean validatePassword(String password) {
		return "dupa".equals(password);
	}
}

Czas na nasz nowy aspekt

Listing 3. Aspekt profilujący.

package pl.koziolekweb.blog.aspectj;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class InputProfilingAspect {

	@Pointcut("call(* java.util.Scanner.next(..))")
	public void profile() {
	}

	@Around("profile()")
	public Object profileAdvice(ProceedingJoinPoint joinPoint) throws Throwable {
		long start = System.nanoTime();
		Object processResult = joinPoint.proceed();
		long stop = System.nanoTime();
		System.out.println("Czas wpisania hasła: "
				+ ((stop - start) * 0.000000001) + " sekundy");
		return processResult;
	}
}

Kolejnym problemem jest konieczność zachowania sygnatury dekorowanej metody. Zatem w przypadku wykorzystania składni @AspectJ jak i .aj należy zadbać by porada zwracała odpowiedni obiekt. Na całe szczęście proceed zwraca Object, a odpowiednie rzutowanie zostaje wykonane poza naszą ingerencją przez weavera. Co jednak w przypadku gdy metoda przyjmuje parametry? Sprawdźmy ile czasu zajmie wypisanie komunikatu powitalnego dla konkretnego użyszkodnika.

Listing 3. Aspekt profilujący z parametrami.

package pl.koziolekweb.blog.aspectj;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class MessageProfilingAspect {

	@Pointcut("call(* Service.welcome(String)) && args(string)")
	public void profile(String string){}

	@Around("profile(string)")
	public void proflieAdvice(ProceedingJoinPoint joinPoint, String string) throws Throwable{
		long start = System.nanoTime();
		joinPoint.proceed(new Object[]{string});
		long stop = System.nanoTime();
		System.out.println("Czas wpisania wiadomości: "
				+ ((stop - start) * 0.000000001) + " sekundy");
	}

}

Jak widać coś jest nie tak. Czasy się nie zgadzają. Czas wypisania komunikatu jest dłuższy niż czas wpisywania hasła. Wniosek, czas jest liczony globalnie. Cóż… takie życie. Wynika to z modelu jaki przyjęto dla tworzenia aspektów. Opisze to później, a na teraz należy pamiętać, że domyślnie aspekty są tworzone jako singletony.

Podsumowania

Wiemy już jakie mamy rodzaje porad. Jeżeli nie rozumiesz jak to działa to nie przejmuj się. Zrozumienie tego modelu tak jak zrozumienie modelu punktów przecięcia wymaga dużo czasu i jeszcze więcej praktyki. W następnej części omówię właśnie model punktów przecięcia. Jest to bardzo ważna i bardzo trudna rzecz. Dlatego też skupię się na podstawowych rodzajach punktów przecięcia.

Dodaj do

• Można stworzyć co najwyżej jedną instancję, obiekt, danej klasy.
• Instancja jest tworzona przy pierwszym użyciu.

O ile pierwszy punkt jest jasny to drugi jest już moim tworem. Ma on na celu rozróżnienie klas singletonów od klas, których wszystkie metody są statyczne. Zakładam więc, że singleton to taki obiekt, który tworzony jest dopiero gdy jest potrzebny, a nie przy ładowaniu klasy. Dobrze zatem spójrzmy jeszcze raz na punkt pierwszy. Moim zdaniem, co znajduje potwierdzenie na angielskiej wiki, singletonem jest każdy obiekt, który potrafi ograniczyć ilość swoich instancji. Oznacza to, że jeżeli nasz obiekt udostępnia tylko pięć instancji samego siebie to też jest singletonem. Tu widać tą małą niedogodność związaną z nazwą wzorca. Powinna ona raczej brzmieć Kontroler Ilości Instancji (ang. Instance Number Controller). Lepiej by oddawała sens tego wzorca. Jednak nie ważne. Ważniejszym pytaniem jest to czy klasa powinna sama dbać o ilość swoich instancji. Jeżeli patrzymy na diagram UML to pierwszą odpowiedzią jest tak. Jak pisał J. Kerievski

Diagram UML wzorca jest tylko jednym z rozwiązań

Tak samo diagram singletona jest jednym z rozwiązań, które są przed nami stawiane. Rzeczą wręcz głupią jest patrzenie na niego i traktowanie jak przenajświętszej ikony w ikonostasie diagramów wzorców projektowych.
Problem ze wzorcem singleton polega przede wszystkim na złym jego wykorzystaniu. Zarówno na poziomie architektury systemu, projektu jak i implementacji. W literaturze omawia się zazwyczaj błędy popełnione w dwóch pierwszych przypadkach. Wielu ekspertów i specjalistów ds. wdrożeń przytacza setki przykładów nieprawidłowego wdrażania singletonów w systemach. Nie spotkałem się jednak z przykładem złej implementacji. Wynika to z trudności wykazania, że dana implementacja jest nieprawidłowa. Znacznie łatwiej jest pokazać, że popełniono błąd w projekcie niż w implementacji. Pytanie dlaczego? Moim zdaniem wynika to z uświęcenia diagramu UML wzorca. Bardzo łatwo poddać się w tym przypadku myśleniu “skoro to jest tak proste to nie należy tego już ulepszać”. Źródła tego sposobu postrzegania znajdują się w generalnej koncepcji wzorców, która mówi, że wprowadzone wzorce powinny upraszczać kod, domyślnie kasować pudełka z diagramu obiektów. Skoro zatem kod (abstrakcja reprezentowana przez UML) jest bardzo prosty to nie można już bardziej go uprościć. Wzorzec singleton jest doskonały, ponieważ nie da się już go bardziej uprościć.
Jednocześnie jeżeli poczytamy o sposobach zamiany wzorca singleton na inny to często przytaczany jest wzorzec fabryki abstrakcyjnej, która dostarcza zawsze tego samego obiektu. Poniższy kod reprezentuje właśnie takie rozwiązanie:

Listing 1. Fabryka czy Singleton oto jest pytanie.

package eu.runelord.blog.singleton;

public class Main {

	public static void main(String[] args) {
		ISingleton singleton = SingletonFactory.getSingleton();
		singleton.helloWorld();
	}

}

class SingletonFactory {

	private static ISingleton singleton;

	public static ISingleton getSingleton() {
		if (singleton == null)
			synchronized (SingletonFactory.class) {
				if (singleton == null)
					singleton = new ISingleton() {

						@Override
						public void helloWorld() {
							System.out.println("Hello World");

						}
					};
			}
		return singleton;
	}
}

interface ISingleton {
	public void helloWorld();
}

Piękny przykład fabryki, która dostarcza nam jednej i tylko jednej instancji klasy singletonu. No właśnie, czy na pewno jest to tylko fabryka…
Wróćmy na chwilę do naszej listy wymagań. Czy nasze nowe rozwiązanie spełnia punkt pierwszy? Na pewno ponieważ udostępnia jedną instancję. Czy spełnia punkt drugi? Też spełnia ponieważ obiekt jest tworzony dopiero przy pierwszym użyciu. Zatem…

Fabryka czy Singleton oto jest pytanie?

No właśnie czy przedstawione powyżej rozwiązanie jest fabryką czy singletonem? Odpowiedź brzmi jest zarówno fabryką jak i singletonem. W tym przypadku nasza fabryka jest jednocześnie specyficzną implementacją, która spełnia założenia singletonu. Z drugiej strony rozwiązanie to jest singletonem, który realizowany jest w oparciu o fabrykę.
Problem z tym konkretnym rozwiązaniem jest taki, że odrzuciłem standardowy diagram UML na korzyść innej drogi. Sam diagram skomplikował się lecz rozwiązanie nadal spełnia wszystkie warunki. Dodatkowo jest znacznie prostsze.
Pytanie brzmi czy moje podejście do problemu jest lepsze? Otóż to zależy. Przedstawiłem jedno ze standardowych rozwiązań, które pretenduje do miana zamiennika dla singletonu. Tak naprawdę 99% złych wdrożeń tego wzorca odbywa się na etapie implementacji, a nie projektowania. Prezentując takie rozwiązanie pomijane jest inne znacznie prostsze, które nawet wygląda jak “prawdziwy” jedno klasowy singleton. Oto i ono:

Listing 2. Rasowy singleton w nowej odsłonie

package eu.runelord.blog.singleton;

public class Main {

	public static void main(String[] args) {
		ISingleton singleton = Singleton.getSingleton();
		singleton.helloWorld();
	}

}

class Singleton implements ISingleton {

	private static Singleton singleton;

	public static Singleton getSingleton() {
		if (singleton == null)
			synchronized (SingletonFactory.class) {
				if (singleton == null)
					singleton = new Singleton();
			}
		return singleton;
	}

	private Singleton(){}

	@Override
	public void helloWorld() {
		System.out.println("Hello World");
	}

}

Czy różni się ono od poprzedniego? Nie! Jedyną różnicą jest konsolidacja kodu fabryki i obiektu biznesowego w ramach jednej klasy. Jednocześnie jeżeli przedstawilibyśmy komuś ten kod i zapytali o wzorce to odpowiedź będzie brzmiała “To jest Singleton.”.

O co cały ten szum…

Mówiłem już, że 99% złych singletonów to dzieci błędnej implementacji. Nie projektu, a właśnie błędnej implementacji. Zanim przejdę do omówienia tego problemu popatrzmy na listę wad singletona:

• Singleton jest trudny do testowania
• Singletonu nie można rozszerzyć
• Singleton łamie zasadę SRP
• Singleton łamie zasadę OCP
• Singleton jest trudny w testowaniu

Programiści to osoby o bardzo zróżnicowanym charakterach i osobowościach. Jednak jeżeli miałbym wybrać jedną cechę, która łączy wszystkich programistów to wybrałbym silne poczucie indywidualizmu. Na spotkaniu WDPSG określiłem siebie jako programistę – artystę. Jest tak ponieważ tak jak każdy artysta poza warsztatem rzemieślniczym posiadam silne poczucie własnej odrębności nawet w grupie osób o podobnych zainteresowaniach.
Po tej malej dygresji popatrzmy jeszcze raz na naszą listę. Czy nie macie wrażenia, że większość problemów związanych z singletonami wynika tak naprawdę z błędów w implementacji wzorca? Przyjrzyjmy się nowej wersji “klasycznego” diagramu UML prezentującego singleton:

Takie nieortodoksyjne podejście i wprowadzenie interfejsu pozwala nam na pozbycie się trzech problemów. Nasz singleton jest już rozszerzalny. Rozszerzyć możemy go poprzez implementację interfejsu. Jeżeli nie chcemy pisać dużej ilości kodu można prowadzić dodatkowy obiekt adaptera, który będzie delegował zachowania do oryginalnego obiektu. My będziemy musieli tylko zaimplementować zmiany. Tym samym nasz singleton nie łamie już zasady OCP. W ogólności nie łamana jest też zasada SRP ponieważ wzorzec wymusza jakąś kontrolę ilości instancji. Sposób jej realizacji może być różny. Można zastosować fabrykę i po problemie. Pozostaje nam jeden problem związany z testowaniem. Tu można wyróżnić dwa rodzaje singletonów.
Pierwszy z nich to singletony bezstanowe. Ich zadanie polega na dostarczaniu metod i nie robieniu tego w sposób statyczny. Te singletony testuje się bardzo, bardzo prosto. Ponieważ na etapie inicjacji testu nie musimy ustawiać żadnych właściwości obiektu nie ma więc potrzeby jakiegoś specjalnego jego traktowania. Powiem nawet więcej, singleton będzie nam ułatwiał życie gdyż inicjację testowanego obiektu trzeba wykonać tylko raz. W tym przypadku problem jest sztuczny, czyli nie istnieje.
Druga grupa to singletony stanowe. Przechowują one pewne dane i tym samym mają stan. Pół biedy jeżeli wszystkie pola są dostępne i można wywołać dla nich metody ustawiające (settery). W takim wypadku wystarczy na etapie czyszczenia po teście zerować pola i ustawiać je na nowo przed każdym testem. Znacznie gorzej ma się sprawa pól do których jedyną metodą dostępu jest refleksja.
Uwaga, będę omawiał teraz zagadnienia związane z Javą i raczej nie znam metod rozwiązania tego problemu w innych językach.
W takim przypadku musimy poszukać jakiegoś obejścia. Kiedyś przedstawiłem już jedno z rozwiązań. Jest ono dość kontrowersyjne, ale się sprawdza. Szczególnie, że można je dość łatwo zaimplementować jako rozszerzenie JUnita.
Gdzie jest w tym myk? Otóż cała magia tego rozwiązania polega na wyrzuceniu wszystkich metod biznesowych do interfejsu. W ten oto prosty sposób realizując założenia wzorca singleton nadal mamy swobodę dostarczania innego rozwiązania. Programiści zazwyczaj nie ekstrahują interfejsu biznesowego i starają się zwalić winę na projektantów. Projektanci też nie są bez winy ponieważ dostarczają programistom diagram UML, w którym bezmyślnie kopiują nie do końca dobre rozwiązania.

Podsumowanie

Wzorzec singleton jest może prosty, ale trzeba umieć go stosować. Wiedza ta potrzebna jest zarówno architektom, projektantom jak i zwykłym programistom ponieważ błędy rodzą się na wszystkich etapach.
Wzorzec singleton jest specyficznym rodzajem fabryki i można to wykorzystać.
W końcu, diagram UML wzorca singleton nie jest świętością i nie należy stosować go w takiej postaci wszędzie. Można zaimplementować singleton na inne sposoby i choć diagram staje się trochę bardziej skomplikowany to nadal jest to singleton.

Dodaj do

Dawno, dawno temu na stercie żył sobie Obiekt Pewnej Klasy (OPK). OPK był bardzo smutny, gdyż nie miał kolegów z którymi mógłby się wymieniać danymi i bawić w gry synchronizacyjne. Dlatego też OPK prosił Programistę:

• - Programisto stwórz mi kolegę bym mógł z nim pracować i się bawić po pracy

Programista widząc, że OPK chce dobra usłuchał jego prośby. Stworzył Kolejny OPK i go zainicjował po czym wrócił do do picia piwa i oglądania filmików.

OPK i KOPK dość szybko stwierdziły, że do brydża trzeba czterech, a potem już we czwórkę, że piłka kopana to co najmniej 22 uczestników. I tak oto O-tyPK mnożyły się i zapełniały RAM i zabierały procesor. Koniec końców, gdy skończyło się piwo, a filmiki z powodu braku zasobów komputera drastycznie zwolniły Programista zajrzał na stertę, zasmucił się i rzekł:

• - Dlaczego żeś mi to uczynił OPK?
• Na co OPK odpowiedział
• - Bo mnie nie przetestowałeś idioto…
• - Oż w żopu… ale i tak masz przestane, bo będziesz Singletonem - rzekł Programista i zabrał się do przerabiania OPK.

Programista kodował całą noc, refaktoryzował kod i przebudowywał referencje. Jednak pamiętając, że obiekt smutny będzie, gdy nie będzie mógł grać w ukochaną synchronizację stworzył mu pola finalne by już nigdy nie pragnął synchronizacji. Po czym powołał OPK do życia i rzekł:

• - Za karę, że mnożyłeś się bez opamiętania uczyniłem Cię Singletonem. nigdy już nie będziesz pragnął grać w Synchronizację. Jeszcze Cię tylko przetestuję.
• OPK popatrzył na siebie i rozradowany rzekł:
• - A Chuja se przetestuj mondziole… Mam pola final i private co raz utworzone nie może być zmienione więc mnie nie przetestujesz, bo konfigurację dostarczasz tylko raz w konstruktorze.

To powiedziawszy OPK dumny z siebie zasiadł w statycznej pamięci.

Problem

Czego uczy nas ta przypowieść? Otóż Singleton jest bardzo dobrym wzorcem wszędzie tam gdzie wiemy, że nie potrzeba więcej niż jednego obiektu danej klasy oraz, wtedy gdy chcemy zaoszczędzić zasoby. Jednakże singletony ciężko się testuje. Dlaczego? Przyjrzyjmy się tej klasie:

Listing 1. Klasa Singleton z polem prywatnym i finalnym

package eu.runelord.blog;

public class Singleton {
	private static Singleton INSTANCE;

	private final String name;

	public static Singleton getInstance() {
		if (INSTANCE == null)
			INSTANCE = new Singleton();

		return INSTANCE;
	}

	private Singleton() {
		this.name = null;
	}

	public String toString() {
		return name;
	}
}

Mamy tu typowy problem. Pole name jest prywatne i finalne jednocześnie. Może się to wiązać z np. odczytem konfiguracji tego pola z pliku properties przy starcie aplikacji i chęci zagwarantowania jej niezmienności. Pytanie brzmi jak przetestować taki obiekt by móc wgrać kilka różnych konfiguracji? Najprościej jest zmienić modyfikatory pól na czas testów. Pomysł głupi ponieważ utrudnia automatyzację testów. Pomysł drugi wykorzystać oddzielne ClassLoadery dla każdego testu. Nieźle, ale trzeba dość dużo pisać w dodatku można popełnić masę błędów. Trzecia metoda użyć mechanizmów Reflection API.

Moja propozycja jest trochę inna. Skoro singleton pozwala na konfigurację z pliku wskazanego przez programistę to wystarczy w każdym teście podawać inny plik i po zakończeniu nullować pole przetrzymujące referencję do naszego obiektu. Przykładowa aplikacja:

Listing 2. Aplikacja która umie nullować Singleton

package eu.runelord.blog;

import java.lang.reflect.Field;

public class App {
	public static void main(String[] args) throws Exception {
		Singleton singleton = Singleton.getInstance();
		System.out.println(singleton);

		Class singletonClass = Singleton.class;
		Field fieldName = singletonClass.getDeclaredField("name");

		fieldName.setAccessible(true);
		System.out.println(fieldName.get(singleton));
		fieldName.set(singleton, "dupa");
		System.out.println(fieldName.get(singleton));

	}
}

Kluczowym elementem całej operacji jest umożliwienie dostępu do pola INSTANCE za pomocą metody setAccessible().

Metoda jest bardzo prosta i przy skomplikowanych testach może się nie sprawdzać, ale na początek wystarczy.

Dodaj do