W tym roku były cztery ścieżki:

• Warsztaty “Google Web Toolkit krok po kroku”, prowadzący Paweł Cesar Sanjuan Szklarz.
• Warsztaty “Meet my Android”, prowadzący Mateusz Grzechociński
• Warsztaty z projektem Domain Driven Design i Command-query Responsibility Segregation Leaven, prowadzący Sławek Sobótka i Rafał Jamróz
• Ścieżka prezentacyjna w składzie:
  • Warsztaty “Obiektowa gimnastyka”, prowadzący Krzysztof Jelski i Paweł Lipiński
  • “WebSphere Application Server v8.0 + OSGi” Grzegorz Abramczyk, prezentacja
  • Do czego jeszcze biblioteki testowe” Bartek Kuczyński, prezentacja z kodowaniem na żywo
  • “Java EE 6 Web Profile z Apache TomEE” Jacek Laskowski, prezentacja

Ze względów organizacyjnych wybrałem ścieżkę numer cztery (jakoś głupio wyjść w środku warsztatów i z bananem na mordzie stwierdzić “wszystko OK, ale mam swoją prezentację, na która zapraszam”). Na tej ścieżce się zatem skupię.

Warsztaty “Obiektowa gimnastyka”

Krzysztof Jelski i Paweł Lipiński zaprezentowali najciekawszą część w całej ścieżce. Przedstawili nam proste zadanie – napisać obsługę konta w banku. Żeby jednak nie było za prosto dostaliśmy też dziewięć zasad tworzenia kodu, których należało przestrzegać:

• Tylko jeden poziom zagłębienia na metodę
• Nie używaj słowa kluczowego else
• Opakowuj wszystkie prymitywy i Stringi (w klasy o specyficznej dla zastosowania nazwie)
• Używaj tylko jednej kropki na linię
• Nie skracaj nazw
• Pilnuj wszystkie encje by były małe
• Nie używaj klas o więcej niż dwóch polach
• Klasa której polem jest kolekcja nie powinna mieć żadnych innych pól (opakowywanie kolekcji w klasy specyficzne dla kontekstu wykorzystania)
• Nie używaj getterów/setterów/własności

Niby proste… ale są haczyki i haki. Zadania było realizowane w parach (co mi się podoba) i dzięki temu było łatwiej. Na przykład dowiedzieć się można, że odejmowanie liczby ujemnej to to samo co dodawanie. Niestety forma warsztatowa wymaga czasu, a tu nam go trochę zabrakło.
Z tych zajęć wyniosłem jednak kilka pomysłów, przemyśleń i naprawdę ogromną ilość wiedzy. Chłopaki spisali się na medal.

“WebSphere Application Server v8.0 + OSGi”

Grzegorz Abramczyk na co dzień pracuje w IBM i zaprezentował nam jak przeprowadzić integrację WAS 8 z OSGi 4.3. Prezentacja ciekawa, na równym poziomie i bez zacięć. Co więcej można o niej powiedzieć? Chyba niewiele więcej, ponieważ była to prezentacja taka jak każda inna przeciętna prezentacja. Bez fajerwerków, ale i bez wpadek. Kawał solidnej roboty, który przyda się tym, którzy będę musieli zagłębić się w dany temat.

Tera byłem ja

I czekam na ocenę w komentarzach

“Java EE 6 Web Profile z Apache TomEE”

Jacek tym razem zaprezentował TomEE, czyli Tomcata 7 podrasowanego by spełniać Web Profile z Javy EE6. Sama prezentacja była o tyle ciekawa, że Jacek podszedł dość luźno do tematu, bo jak sam stwierdził, cytując z pamięci:

Nie przejmuję się tym z jakim nastawieniem wyjdziecie.

co spowodowało duże rozluźnienie, a w efekcie super efekt. W ramach przykładów było nie tylko pokazanie, że Web Profile na TomEE działa prawidłowo, ale też otrzymaliśmy przegląd tego co niespodziewanego może nam się przydarzyć w trakcie pracy nad projektem w NetBeans 7.1. Całość okraszona humorem “z naszego potworka”.

Podsumowanie

Tegoroczna Warsjawę uważam, za udaną. Jedyne do czego można się przyczepić to brak nagrywania prezentacji, ale z drugiej strony Jacek “do it yourself”, a ja też jestem baran, bo zapomniałem kamery
Jak obiadek była pizza na koszt sponsorów, a na zakończenie rozlosowano nagrody (w końcu coś wygrałem). I tym pozytywnym akcentem kończę relację.

ps. o zasadach przedstawionych przez Pawła i Krzyśka pewno będę jeszcze pisał, ponieważ po tym krótkim teście wiem, że są bardzo pomocne.

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