Instalacja softu

Z tej strony pobieramy odpowiedni dla nas pakiecik i restartujemy Eclipse. Zakładam, że wiesz jak instalować plugin eclipsowy za pomocą Update Site. Jeżeli nie to sorry Winnetou. Kurs będzie mocno Eclipse only.
Następnie tworzymy nowy projekt AspectJ. Zostaniemy zapytani czy chcemy włączyć mechanizm weaveringu i zrestartować Eclipse. Oczywiście włączamy go i restartujemy IDE.

Podstawowe pojęcia

W tradycyjnym modelu obiektowym gdy zaczynamy pisać program to okazuje się, że w pewnym momencie należy do naszego kodu dodać kilkanaście różnych ciekawych czy nie, ale wymaganych funkcjonalności. Zazwyczaj jest to logowanie, kontrola dostępu, jakieś duperele związane z profilowaniem. Robiąc to za pomocą klasycznych metod zazwyczaj łamiemy dwie zasady. Po pierwsze SRP ponieważ nasza klasa zaczyna mieć wiele odpowiedzialności. A to logowanie, a to security, a tu jeszcze admin mówi, żeby włączyć profilowanie w jednym miejscu i natłuc raportów. Poza tym robi się burdel w kodzie. Oczywiście w pewnym momencie dochodzimy do wniosku, że większość z tych bajerów nie jest nam potrzebna i łamiemy OCP. Ponieważ by je wyłączyć zaczynamy grzebać w oryginalnym kodzie. Tu z pomocą przychodzą nam aspekty. Aspekt jest to moduł aplikacji zawierający jakąś funkcjonalność, która jest wtłaczana do kodu za pomocą kompilatora aspektowego. Aspekt jest opisany za pomocą specjalnego języka, na którego podstawie kompilator odpowiednio modyfikuje kod wynikowy w procesie kompilacji. Poniżej kilka ważnych pojęć
Punkt dostępu – ang. Join Point – dowolny punkt w kodzie, w którym kompilator aspektowy może wstawić kod aspektu. To czym jest ten punkt zależy od konkretnej implementacji języka aspektowego. W przypadku AspectJ są to metody, klasy, pola.
Punkt przecięcia – ang. Pointcut – konkretny punkt dostępu do którego stosowany jest dany aspekt.
Porada – ang. advice – kod który jest wstawiany.
Wiem, że osoby, które miały do czynienia z programowaniem aspektowym uznają ten opis za uproszczony, ale KISS MY ASS (Keep Is Simple Stupid. Mayby You Are Support Soft).

Co to jest AspectJ?

Znowu upraszczając jest to rozszerzenie języka Java o kilka słów kluczowych i mechanizm weaveringu, czyli właśnie wkompilowywania kodu. Inaczej rzecz ujmując jest to biblioteka, która zawiera specjalny kompilator, będący rozszerzeniem kompilatora javy o funkcjonalność jaką jest obsługa aspektów. Zawiera specjalnego agenta JVM, który może wykonać pracę kompilatora w trakcie ładowania kodu. Jest to zacne i przydatne rozwiązanie.
AspectJ wspiera dwa rodzaje składni. Pliki .aj, które są “naturalne” w jego środowisku oraz mechanizm oparty o adnotacje i zwykłe klasy javy. Przy czym każdy prawidłowy plik java jest prawidłowym plikiem aspektowym. Koniec końców AspectJ jest tylko rozszerzeniem języka (trochę jak C++ do C), a nie czymś całkowicie nowym.

Zajawka

Dzisiejszą część poświęcimy tylko na prostą aplikację w tylu “hello world”, ale pozwoli ona załapać Ci jak działa programowanie aspektowe. Na początek mamy kod taki jak poniżej:

Listing 1. Bazowa aplikacja

package pl.koziolekweb.blog.aspectj;

public class Main {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		Service service = new Service();
		service.welcome();
		service.welcome("Koziołek");
	}

}
//....
package pl.koziolekweb.blog.aspectj;

public class Service {
	public void welcome() {
		System.out.println("Witamy w systemie");
	}

	public void welcome(String name) {
		System.out.println("Witaj " + name);
	}
}

Naszym zadaniem jest zabezpieczyć aplikację przed niepożądanymi wywołaniami. Posłuży nam do tego specjalna klasa NKWD:

Listing 2. Klasa NKWD – odpowiada za bezpieczeństwo

package pl.koziolekweb.blog.aspectj;

import java.util.Scanner;

public class NKWD {

	private boolean isAuth = false;

	public void auth() {
		if (isAuth) {
			return;
		} else {
			System.out.print("podaj hasło: ");
			Scanner scanner = new Scanner(System.in);
			String password = scanner.next();
			if ("dupa".equals(password)) {
				isAuth = true;
			}
			else{
				throw new RuntimeException("Wypad na Łubiankę");
			}
		}
	}
}

Pytanie co zrobimy w klasycznym podejściu? Pewno wystarczy utworzyć fabrykę obiektów NKWD, która będzie dbała o to by do każdego wątku był przyporządkowany odpowiedni obiekt NKWD. Będziemy go pobierać w każdej metodzie i w razie czego sprawdzać… no cóż… chłopaki od php zapewne by na tym poprzestali, ale mają łatwiej, bo jest u nich funkcja require_once i przetwarzanie skryptu zatem można takie sztuki robić. My niestety używamy języka programowania i zastosujemy programowanie aspektowe.
Stworzymy zatem aspekt, który będzie przed każdym wywołaniem metody welcome sprawdzał czy wszystko śmiga.

Listing 3. Nasz pierwszy aspekt

package pl.koziolekweb.blog.aspectj;

public aspect SecurityAspect {
	private NKWD nkwd = new NKWD();

	pointcut auth() : call( * Service.welcome(..));

	before() : auth() {
		System.out.println("NKWD działa");
		nkwd.auth();
	}
}

Kompilujemy i uruchamiamy jako aplikację AspectJ. Efekt:

Listing 4. wyniki działania naszego pierwszego aspektu

NKWD działa
podaj hasło: dupa
Witamy w systemie
NKWD działa
Witaj Koziołek

Chwila ze składnią

Za pomocą słowa pointcut definiujemy miejsce przecięcia. Format jest dość swobodny w przypadku AspectJ zazwyczaj używamy składni bardzo zbliżonej do UMLowego definiowania sygnatur metod. Znak * oznacza dowolne słowo, a .. dowolną ilość słów.
Słowo before wskazuje, że dana porada będzie uruchamiana przed wywołaniem dowolnej metody pasującej do wskazanego punktu przecięcia.

Podsumowanie

Czytam “AspectJ in Action” i mam nadzieję, że powstanie kacusiowa recenzja.

Dodaj do

Witam w czwartej części cyklu S.O.L.I.D.ne Programowanie. Dzisiejszy temat zajęć to Interface Segregation Principle (ISP).

Co mnie to obchodzi?

Często gdy trafiamy na jakiś interfejs pierwszą myślą jest po kiego wała oni tu wpakowali tyle metod? Nadmiernie rozbudowana lista metod zaciemnia interfejs i powoduje, że jest on trudny w użyciu. ISP mówi nam, że:

Klient nie powinien być uzależniony od interfejsów z których nie korzysta.

Mówiąc prościej klient powinien operować na interfejsie zawierającym tylko potrzebne mu metody.

Nietzscheańska idea nad interfejsu

Jako, że sam popełniam ten błąd to zacznę od określenia czym jest super interfejs.
Super Interfejs jest to interfejs, który skupia w sobie wszystkie potrzebne w danej chwili metody i nie uwzględnia ich zadań. Inaczej mówiąc jest to interfejs, który łamie zasadę SRP. Zdefiniujmy przykładowy interfejs Robotnik:

Listing 1. Super interfejs – Robotnik

package pl.koziolekweb.solid.isp;

public interface Robotnik {

	public void pracuj();

	public void pobierzWyplatę();

}

Przyjrzyjmy się teraz dwóm innym interfejsom, które korzystaja z naszego robotnika. Manager i Księgowy.

Listing 2. Interfejsy klienckie – Manager i Księgowy

package pl.koziolekweb.solid.isp;

public interface Manager {

	public void dodajPracownika(Robotnik robotnik);

	public void zarządzaj();
}
// .... //
package pl.koziolekweb.solid.isp;

public interface Księgowy {

	public void przyjmijNaStan(Robotnik robotnik);

	public void wypłaćPensję();

}

Od razu widać co jest nie tak?

Czy roboty mają uczucia?

Dobre pytanie. Przypowieść programistyczna na temat ISP. Dawno dawno temu była sobie fabryka. W fabryce pracowali robotnicy, managerowie i księgowi. Robotnicy wykonywali swoje zadania, managerowie kontrolowali robotników i zlecali księgowym wypłacanie pensji. Jednak któregoś dnia prezes postanowił, że część prac wykonywać będzie robot. Zgodnie z procedurą robot został wciągnięty na listę nadzoru managerskiego i był pod opieką jednego z managerów. Gdy nadszedł dzień wypłaty manager przekazał listę swoich pracowników do księgowych, a ci rozpoczęli wykonywanie przelewów. Nastąpiła jednak konsternacja wielka wśród księgowych bo nikt nie wiedział jak poradzić sobie z problemem robota. Z jednej strony był on pracownikiem i należało mu się wynagrodzenie, a z drugiej jednak był tylko maszyną… konsternacja trwała tak długo, że inni robotnicy nie otrzymali swych wypłat, spalili opony przed siedzibą zarządu fabryki, a ta upadła.
Jedynie robot zaśmiał by się z zaistniałej sytuacji oczywiście gdyby miał uczucia.

Zmiana punku widzenia

Gdy zapytasz się twórcy interfejsu co miał na myśli tworząc interfejs Robotnik najprawdopodobniej usłyszysz, że robotnik przecież pracuje i otrzymuje wypłatę. Jeżeli jednak popatrzymy na ten problem z punktu widzenia managera to ważna jest tylko praca, ale znowu punkt widzenia księgowego bierze pod uwagę tylko wypłatę wynagrodzenia. Interfejs powinien definiować metody związane z zadaniem, ale z punktu widzenia użytkownika tego zadania, a nie klasy implementującej. Bardzo dobrym przykładem jest tu interfejs Comparable i jego użycie w narzędziach do sortowania kolekcji. Metoda sortująca żąda tylko czegoś co jest Comparable, czyli ma tylko jedną metodę compareTo. Nie jest dla narzędzia istotne jakie inne zadania ma obiekt. Ma tylko mieć możliwość porównania się z innym obiektem.

Naprawiamy świat

Interfejs Robotnik jest zły. Ponieważ klasa, która będzie go implementować MUSI uwzględniać zarówno fakt, że robotnik pracuje jak i fakt, że otrzymuje pensję. Jeżeli na stan wprowadzimy klasę Robot, której obiekty nie będą wymagały pensji, ale będą pracowały to albo księgowy będzie musiał jakoś sobie poradzić z błędami albo programista będzie musiał jakoś tak zaprojektować robota, żeby ten przyjmował bezpieczną pensję (np. 0). Rodzi to kolejne trudności jak na przykład uwzględnienie przy wypłacie grupy zaszeregowania, wysługi lat, amortyzacji itp. Problem taki będzie propagował się na inne części systemu, a lokalnie tworzone obejścia będą tylko utrudniały utrzymanie kodu.
Prawidłowym rozwiązaniem jest rozbicie interfejsu Robotnik na dwa interfejsy. Pracujący i Opłacany:

Listing 3. Interfejsy – Pracujący i Opłacany

package pl.koziolekweb.solid.isp;

public interface Pracujący {

	public void pracuj();

}
// .... //package pl.koziolekweb.solid.isp;

public interface Opłacany {

	public void pobierzWyplatę();

}

Zmianie ulegną oczywiście interfejsy Manager i Księgowy.

Listing 4. Interfejsy klienckie – Manager i Księgowy, nowa wersja

package pl.koziolekweb.solid.isp;

public interface Manager {

	public void dodajPracownika(Pracujący robotnik);

	public void zarządzaj();
}
// .... //
package pl.koziolekweb.solid.isp;

public interface Księgowy {

	public void przyjmijNaStan(Opłacany robotnik);

	public void wypłaćPensję();

}

Oczywiście te zmiany to tylko początek. Kolejnymi powinno być pozmienianie klas fabrykujących poszczególne rodzaje obiektów tak by roboty i ludzie trafiali do odpowiednich kolejek. Refaktoryzacja kodu, którą powoduje ISP zazwyczaj jest bardzo głęboka. Dlatego też należy stosować segregację interfejsów już na samym początku, a jeżeli zachodzi konieczność podziału interfejsu należy robić to natychmiast po zauważeniu tak by zmiany dotknęły jak najmniejszą część systemu.

Inne zalety

ISP powoduje tworzenie dużej ilości małych interfejsów (w skrajnym przypadku jedna metoda na interfejs) oraz rozwlekanie się definicji metod o kolejne elementy do implementacji. Choć wydaje się to głupie to takie rozwiązanie ma same zalety. Po pierwsze kod kliencki zawsze dostanie to czego potrzebuje w danej chwili. Po drugie nic nie broni łączyć interfejsów:

Listing 4. Interfejs połączony – RobotnikCzłowiek

package pl.koziolekweb.solid.isp;

public interface RobotnikCzłowiek extends Pracujący, Opłacany {
}

Jeżeli zachodzi taka potrzeba. Jest to szczególnie przydatne w klasach fabrykujących, które pracują według wzorca budowniczego. Dostarczają one potrzebny element zachowując jednocześnie wszystkie właściwości jego części. Po trzecie znacznie ułatwia to pisanie testów jednostkowych. Testowaniu podlega wtedy prosty interfejs co pozwala na znacznie lepsze napisanie przypadków testowych uwzględnienie różnych danych skrajnych i uzyskanie lepszego pokrycia kodu. Test staje się prawdziwie jednostkowy ponieważ testuje najmniejszą jednostkę kodu jaką jest metoda. Po czwarte podobnie jak z testami sprawa ma się z dokumentacją. Łatwiej jest udokumentować działanie pojedynczej metody. Można dokładnie opisać co robi, niż napisać dokumentację dla złożonego interfejsu w której uwzględniamy kontekst wywołania czy wpływ innych nie powiązanych metod (opis jak działa wypłacanie pensji dla robota skoro nie powinien on w ogóle pensji dostawać).
ISP jest jedną z najprzydatniejszych zasad programowania obiektowego i warto ją stosować zawsze i wszędzie.

Dodaj do

Witam w trzeciej części cyklu S.O.L.I.D.ne Programowanie. Dziś na warsztat bierzemy Liskov Substitution Principle (LSP).

Nie kijem go to pałą

Efekt powinien być ten sam. Zasada Podstawienia Liskowa jest prosta, ale może przysporzyć problemów.

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

Względnie znacznie szerzej znana definicja matematyczna tego problemu:

Dla każdego X i Y należącego do zbioru R, takich że X = Y, jeżeli F(X) odwzorowuje X w zbiorze R to F(Y) też odwzorowuje Y w zbiorze R tak, że F(X) = F(Y)

Jednym zdaniem wymiana implementacji nie powinna wpływać na kod klienta.

Kij

LSP jest, jak już pisałem, dość prosta. Jednocześnie należy zwrócić uwagę na fakt, że czasami realizacja tej zasady jest niemożliwa. Co ciekawe są to dość częste przypadki i należy pamiętać o nich.
Do rzeczy. Po pierwsze co mów nam ta zasada to to, że jeżeli klasę A zamienimy klasą B, która dziedziczy z A to klient nie powinien otrzymać innych wyników. Ważna rzecz, o której wszyscy zapominamy LSP dotyczy tylko klas dziedziczących po sobie, a nie implementacji interfejsów. Szczególnie interfejsów uogólnionych, czyli takich które pozwalają na realizację wielu funkcjonalności za pomocą jednego spójnego API.

Przykład 1. Filtr tekstu

Przykładem kodu, który nie podpada pod LSP jest kod filtrujący. Załóżmy, że użytkownik wywołuje zdalnie metodę procced(String):String. Ciężko jest wymagać, by wszystkie filtry działały w ten sam sposób i wykonywały takie same operacje. Dlatego też wybór konkretnej implementacji spada na użytkownika. To on wykonuje wymianę implementacji i ponosi wszelkie konsekwencje tej zmiany.

Listing 1. Kod niepodlegający LSP

package pl.koziolekweb.solid.lsp;

public class App {
	public static void main(String[] args) {
		// kod użytkownika
		String abc = "abc";
		TextFilter filter = new AFilter();
		System.out.println(filter.procced(abc));
		filter = new BFilter();
		System.out.println(filter.procced(abc));
	}
}

// nasz kod
interface TextFilter {

	public String procced(String text);

}

class AFilter implements TextFilter {

	public String procced(String text) {
		return text.replaceAll("a", "");
	}
}

class BFilter implements TextFilter {

	public String procced(String text) {
		return text.replaceAll("b", "");
	}
}

W kodzie klienta nastąpiła wymiana implementacji i pociągnęła ona za sobą zmianę zachowania. Klient może mieć pretensje tylko do siebie ponieważ z pełną świadomością wymienił implementację na inną.

Pała

Skoro istnieje kod, który po d LSP nie podpada to muszą istnieć też miejsca dla których LSP ma zastosowanie. Powróćmy do naszego przykładu i załóżmy, że zmieniamy implementację AFilter.

Listing 2. LSP w praktyce – poprawnie

package pl.koziolekweb.solid.lsp;

public class App {
	public static void main(String[] args) {
		// kod użytkownika
		String abc = "abc";
		TextFilter filter = new AFilter();
		System.out.println(filter.procced(abc));
		filter = new BFilter();
		System.out.println(filter.procced(abc));
	}
}

// nasz kod
interface TextFilter {

	public String procced(String text);

}

class AFilter implements TextFilter {

	public String procced(String text) {
		try{
			//coś ekstra liczymy
		}catch (Exception e) {

		}
		return text.replaceAll("a", "");
	}
}

class BFilter implements TextFilter {

	public String procced(String text) {
		return text.replaceAll("b", "");
	}
}

Listing 3. LSP w praktyce – niepoprawnie

package pl.koziolekweb.solid.lsp;

public class App {
	public static void main(String[] args) {
		// kod użytkownika
		String abc = "abc";
		TextFilter filter = new AFilter();
		System.out.println(filter.procced(abc));
		filter = new BFilter();
		System.out.println(filter.procced(abc));
	}
}

interface TextFilter {

	public String procced(String text) throws Exception;

}

class AFilter implements TextFilter {

	public String procced(String text) throws Exception{

			//coś ekstra liczymy

		return text.replaceAll("a", "");
	}
}

class BFilter implements TextFilter {

	public String procced(String text) throws Exception{
		return text.replaceAll("b", "");
	}
}

tu leży pies pogrzebany. Zmieniliśmy implementację kodu. Na listing 2. zrobiliśmy to w prawidłowy sposób zamykając nowe ciekawe możliwości wewnątrz metody. Na listingu 3. zmiany nie dość, że spowodowały zmianę API to dodatkowo kod klienta nie kompiluje się. Czyli jest źle.
W javie mamy @Deprecated, która służy od oznaczania kodu przestarzałego. Jedyną możliwością wycofania metody lub klasy z API oznaczenie jej jako przestarzałej. LSP chroni użytkownika przed niepodziewanymi zmianami w działaniu kodu jak i zmianami API.

Listing 4. LSP w praktyce – poprawnie

package pl.koziolekweb.solid.lsp;

public class App {
	public static void main(String[] args) {
		// kod użytkownika
		String abc = "abc";
		TextFilter filter = new AFilter();
		System.out.println(filter.procced(abc));
		filter = new BFilter();
		System.out.println(filter.procced(abc));
	}
}

// nasz kod
interface TextFilter {

	@Deprecated
	public String procced(String text);

	public String proccedAndThrow(String text) throws Exception;

}

class AFilter implements TextFilter {

	@Deprecated
	public String procced(String text) {
		return text.replaceAll("a", "");
	}

	public String proccedAndThrow(String text) throws Exception {
		// coś ekstra liczymy
		return text.replaceAll("a", "");
	}
}

class BFilter implements TextFilter {

	@Deprecated
	public String procced(String text) {
		return text.replaceAll("b", "");
	}

	public String proccedAndThrow(String text) throws Exception {
		return procced(text);
	}
}

Prawidłowe rozwiązanie, które zachowując LSP pozwala na wprowadzenie nowego inaczej zachowującego się kodu.

Podsumowanie

Choć LSP jest bardzo prosta w zrozumieniu i użyciu to należy pamiętać, że istnieje kod, który tej zasadzie nie podlega. LSP należy używać mądrze, a nie zawsze.

Dodaj do

Witam w drugiej części cyklu “S.O.L.I.D.ne programowanie”, poświęconego zasadom S.O.L.I.D. Dziś przyjrzymy się bliżej Open-Close Principle (OCP).

Ciężko było mi wyszukać jakiś elegancki przykład no i czasu było mało, ale przepraszam za opóźnienia. Jedziemy.

Drogie panie otwieram nasz kram…

Dobry kod obiektowy powinien cechować się dużą elastycznością. Elastyczność to przede wszystkim umiejętność szybkiego dostosowania się do nowych wymagań. Szybkie dostosowanie oznacza przede wszystkim małą liczbę zmian. Wynika to z faktu, że zmieniany kod trzeba testować. W dodatku zmiany wpływają na inne elementy aplikacji i je też trzeba testować. Zasada OCP mówi:

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.

Jako, że zmiany są jedyną pewną i niezmienną rzeczą z jaka mamy do czynienia w programowaniu, więc kod, który nie umie się zmieniać jest do wyrzucenia. Sama zasada jest przewrotna, bo cóż oznacza otwartość na zmiany i jednoczesna niemożliwość modyfikacji?
Ta przewrotność jest jednocześnie pewną filozofią. Wraz z kolejnymi zasadami odkryjemy, że celem S.O.L.I.D. jest takie konstruowanie kodu by zmiany w jego działaniu nie wpływały na kod klienta.
OCP można realizować w kilku aspektach. Przyjrzymy się wszystkim po kolei. Każdy z nich dotyczy innego zagadnienia, ale wszystkie należą do zagadnień związanych z organizacją kodu.

Dziedziczenie nie jest złe

Od wielu lat wbija się do głowy kolejnym pokoleniom programistów Java, że nie powinni używać dziedziczenia, ale implementować interfejsy. Jest to o tyle słuszne, że mało kto potrafi zaproponować odpowiedni sposób dziedziczenia. Przez sposób rozumiem tu zarówno realizację dziedziczenia w aplikacji jak i motywację i uzasadnienie tejże.
Powróćmy do naszego przykładu z pierwszej części. Przedstawiony tam przykład modemu będzie nam służył w tym artykule. Załóżmy, że chcemy rozszerzyć funkcjonalność modemu o obsługę WiFi. Co powinniśmy zatem zrobić? Najprościej jest zmienić tak implementację by możliwe było przyjmowanie połączeń nowym kanałem. Zmiany tej dokonujemy przez stworzenie dekoratora, który otoczy standardową implementację i doda odpowiednią funkcjonalność. To jest dobre OCP. Nie zmieniamy już gotowego kodu, a tylko nieinwazyjnie dodajemy do niego odpowiednie funkcjonalności.
Złym OCP będzie grzebanie bezpośrednio w kodzie, ale najgorszym będzie pisanie wszystkiego od nowa.
Na tym poziomie mówimy o OCP w odniesieniu do funkcjonalności kodu. Przyjrzyjmy się teraz samym obiektom.

Gettery i Settery to nie hermetyzacja

Co tu dużo mówić, jeżeli w naszych obiektach wszystkie pola mają metody ustawiające to nie możemy mówić o OCP. Kod tego typu nie jest zamknięty na modyfikacje ponieważ w pełni został ujawniony. Publikować należy zatem tylko to co jest naprawdę niezbędne i robimy to w sposób bezpieczny wielowątkowo.

Pakiet

Poruszyliśmy już temat funkcjonalności kodu i API klasy. Ostatnim zagadnieniem jest odpowiednie publikowanie modułów. Zazwyczaj moduły mają bardzo dużo klas publicznych. OCP jest przeciwnikiem publikowania elementów zmiennych. Prawidłowo skonstruowany moduł powinien umożliwiać jego rozszerzenie w dowolnym punkcie, ale bez możliwości zmiany kodu modułu. Oznacza to, że należy ograniczyć możliwość takiego rozszerzania klas, które realizują zadania wewnątrz modułu, że ingerujemy w moduł np. zmianiając konfigurację fabryk.

Podsumowanie

OCP jest bardzo dziwną zasadą, która nie jest oczywista do puki czegoś nie popsujemy. Zapraszam zatem do dyskusji o różnych aspektach OCP.

co ja mam dziś z tymi aspektami

Dodaj do

Witam na pierwszym spotkaniu z zasadami S.O.L.I.D. Temat zajęć Single Responsibility Principle. Ok koniec oficjalnego języka…

Kod jest rodzaju męskiego

Czytałem gdzieś ostatnio, że mężczyzna jest istotą zdolną do wykonywania jednej czynności naraz. Książka była o tym jak tworzyć udany związek i pisała ją jakaś anarcho-feministka. Ma jednak rację. Mężczyzna nie potrafi robić kilku rzeczy naraz. Wynika to z tego prostego faktu, że chcemy nasza pracę wykonywać dobrze to się na niej skupiamy.
Podobnie ma się rzecz dobrym kodem.

THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE

Ten cytat jest zazwyczaj podawany jako clou jeśli chodzi o regułę SRP. Oznacza ona, że zamiany w kodzie mogą być spowodowane tylko przez jedną i tylko jedną przyczynę. Ma to bardzo dobre uzasadnienie w praktycznych rozwiązaniach. Pojedyncza odpowiedzialność pozwala na separację poszczególnych modułów i tym samym utrzymanie kodu staje się łatwiejsze. Sięgając po jakąś klasę od razu wiemy kto zacz.
Wspominałem o tym, że jeżeli działania kodu nie można opisać w trzech zdaniach to należy go refaktoryzować. Pojawia się tam też odniesienie do poziomu abstrakcji w ramach którego działamy. No właśnie…

Jeden powód do zmian != jedna czynność

SRP jest prostą regułą, którą wprowadzają osoby, które trochę programują. Jest to samo narzucająca się zasada. Pozwala na unikanie duplikacji kodu, tworzenie modułów Jest to jedna z najbardziej intuicyjnych rzeczy w projektowaniu. Podobnie jak w przypadku singletona można jednak popaść w poważne tarapaty jeżeli nie rozumie się do końca zasady działania. Mam doskonały przykład jak nie stosować SRP. Zaprogramujmy Modem.

Złe SRP

Modem powinien posiadać następujące funkcje:

• Powinien umożliwiać nawiązanie połączenia.
• Powinien umożliwiać zerwanie połączenia
• Powinien umożliwiać wysłanie wiadomości
• Powinien umożliwiać odbieranie wiadomości

Te cztery funkcjonalności składają się na modem. Warto zauważyć, że nie są one ze sobą sztywno powiązane. Jedyne zależności wynikają z przymusu zachowania kolejności wywołania metod (najpierw połączenie potem komunikacja i na końcu rozłączenie). Tworzą one dwie grupy. Pierwsza odpowiada za połączenie, druga za komunikację. Mamy już zatem dwa interfejsy. Pierwszy będzie zawierał metody connect() i disconnect(), a drugi send() i receive(). Programista będzie używał tych dwóch interfejsów, ręcznie nawiązywał i zrywał połączenie wysyłał dane i je odbierał. Pakujemy nasz kod do biblioteki nazywamy modem i zgarniamy kasiorkę… a tu dupa. Generalnie takie podejście jest przykładem złego SRP. Na pierwszy rzut oka odseparowaliśmy odpowiedzialności. Każda z klas ma tylko jeden powód do zmian. Są to odpowiednio zmiana sposobu komunikacji dla klasy Connector i zmiana formatu komunikatów dla klasy Communicator. Jednak nie wykonaliśmy głównego zadania. Nie mamy modemu! Mamy zestaw luźno powiązanych klas, które wrzuciliśmy do jednego wora i nazwaliśmy modem.
Problemem okazuje się zachowanie poziomu abstrakcji przy jednoczesnym stosowaniu SRP. Reguła prowadzi do rozdrobnienia kodu. Jednocześnie zanika nam główny problem. To tak jakbyśmy zamiast na pustynię patrzyli na zbiór ziarenek piachu.

Dobre SRP

Dobre rozwiązanie tego problemu polega na zastosowaniu odpowiedniego poziomu abstrakcji dla modemu. W pierwszym kroku musimy zmodyfikować nasze wymagania:

• Modem umożliwia komunikację z X

Modem jak widać ma z definicji jedno zadanie. Umożliwić komunikację. Sposób realizacji tego zadania jest na niższym poziomie. Nadal jedynym powodem zmian jest zmiana sposobu komunikacji, ale nie jest tu już istotne który element się zmienił. W praktyce modem powinien mieć tylko dwie metody send() i setMessageTarget(). Pierwsza powinna pozwalać na wysłanie wiadomości, a druga na ustawienie miejsca, w które powinny być przekazane wiadomości przychodzące. Klient jest zadowolony, modem ma jedną odpowiedzialność, a w szczegóły nie wnikamy.

Praktyka

Przykład z modemem może wydawać się błędny. W drugim przypadku modem ma wiele odpowiedzialności, ale tylko z punktu widzenia kombinatora. Z punktu widzenia klienta realizuje on dwa zadania w ramach jednej odpowiedzialności – wysyła i pobiera komunikaty. Klienta nie interesują szczegóły. W samym modemie realizowany jest odpowiedni algorytm i jego zmiana jest jedynym powodem zmiany w klasie. Oczywiście poszczególne elementy algorytmu są realizowane przez kolejne podzespoły – klasy i metody, które odpowiadają za coraz węższą działkę.
Zasada jednej odpowiedzialności w praktyce oznacza umiejętne delegowanie bardziej szczegółowych zadań do osobnych klas i metod. Dana klasa realizuje tylko abstrakcyjne zadanie nie wnikają w szczegóły kolejnych kroków.

Dodaj do

• Single Responsibility Principle
• Open-Close Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Ten wpis będzie tylko wstępem w którym omówię czym są te zasady, skąd się wzięły i dlaczego są ważne.

OOP i programiści

Jeżeli zapytamy statystycznego programistę z czym kojarzy mu się dobry kod OO to najprawdopodobniej będzie mówił o wzorcach projektowych. Co poniektórzy wspomną o zasadach projektowania, enkapsulacji i hermetyzacji, dziedziczeniu, interfejsach. Niewielu wspomni o zasadach S.O.L.I.D.
Nic w tym dziwnego, bo zasady te nie są sformalizowane tak jak wzorce. Dobrze określił je Krzysiek na spotkaniu mówiąc, że są raczej przysłowiami. Ja bym raczej nazwał je powiedzeniami informatyków. Każda z tych zasad odnosi się do jakiegoś bardzo ogólnego zagadnienia czy to projektowego, czy to architektonicznego czy też funkcjonalnego. Zazwyczaj do wszystkiego po trochu.
Jako, że nie ma tu formalizacji więc nie można mówić o miejscach i sposobach stosowania czy problemach, które można rozwiązać. Jeżeli jednak przyjrzymy się wzorcom projektowym, to dojdziemy do wniosku, że wszystkie one zawierają w sobie te nieformalne zasady.

Plan pracy

Przez kolejne dni będę omawiał poszczególne zasady. Jedna zasada na jeden wpis.

Dodaj do