Przemyślane praktyki Java EE

Dziś krótka recenzja książki Adama Biena Real World Java EE Patterns - Rethinking Best Practices.

Zacznę od konkluzji: czy warto? Tak. To jak bardzo warto zależy od Twojego dotychczasowego backroundu, ale gwarantuję, że nawet eksperci Javy EE znajdą dla siebie kilka ciekawych kawałków. Pozycja konkretna, na temat, z przykładami wykorzystującymi ciekawe kruczki z np. EJB 3.1.

Na początku obawiałem się, że przemyślenia dotyczą trywialnych CRUDów - na crudach opiera się ostatnio cała współczesna literatura programistyczna jak i blogi. Nie dziwota, gdyż jest to bardzo wdzięczna materia - można na nich pokazać jak prosta i łatwa jest technologia X, a później radźcie sobie sami.

Autor w części rozdziałów wychodzi od crudów jednak za chwilę porusza bardziej zaawansowane tematy, racjonalnie argumentując kiedy opłacalne jest wprowadzenie bardziej złożonych mechanizmów platformy.

Dla kogo przeznaczona jest książka?
Przede wszystkim dla weteranów J2EE, którzy przesiadając się na Java EE powinni zapomnieć stare nawyki.
Dla osób zaczynających od EE 5 lub przechodzących z innych technologii (Spring) odniesienia do "starych" praktyk będą jedynie ciekawostką archeologiczną.

Ale tak jak pisałem, znajdziemy w niej kilka ciekawych kruczków, sporo gotowych rozwiązań oraz dużo gotowego kodu. Kruczki i best practices związane z transakcjami, kod użytecznych interceptorów, które łatają braki w specyfikacji;) oraz nieco praktyk odnośnie dobrego designu. Część praktyk odnośnie designu jest dyskusyjna, jednak autor wyjaśnia w dalszej części, że aplikują się w pewnych kontekstach, natomiast gdy wymaga tego problem, wówczas zaczynamy sięgać po inne rozwiązania. Przykładowo obiekty transferowe są dobre tylko wtedy gdy są dobre:) - z czym nie sposób się nie zgodzić. DAO jest usprawiedliwione tylko gdy wnosi wartość - tak ale dyskutować można nad tym co jest wartością.

Mimo dyskusyjności niektórych pomysłów trzeba docenić inicjatywę, ponieważ generalnie brakuje na rynku pozycji wychodzących poza przysłowiowy Hello World...


Na uwagę zasługuje fakt, że autor otwarcie mówi o proceduralnym stylu promowanym przez platformę.
Mówi też otwarcie o innych sposobach skalowania - bez rozpraszania obiektów pomiędzy warstwami...
nota bene zgodnie z zasadą Fowlera odnośnie rozpraszania: "Just don't":)



Nie byłbym sobą gdybym nie znalazł jakiś błędów koncepcyjnych...
Wiem, że w każdej książce technicznej (w sensie opisującej jakąś technologię) projektowanie Object Oriented jest potraktowane po macoszemu ale skoro już polecam książkę to zwrócę uwagę na 2 przykłady:

Rozdział "Persistent Domain Object (Business Object)"
Po wstępie o tym dlaczego opłaca się stosować model OO (rich model) zamiast proceduralnego (anemic model) mamy taki oto przykład:

Klasa OrderItem, która między innymi potrafi policzyć swój koszt metodą getShippingCost (jest to metoda biznesowa a nie geter)

Dalej dziedzicząca po niej klasa BulkyItem, która liczy koszt nieco inaczej - nadpisuje metodę getShippingCost a w niej woła super wersję tej metody!

@Override
public int getShippingCost() {
return super.getShippingCost() + 5;
}



Nie róbcie tego w domu ani w pracy!:)
1. OrderItem ma wiele odpowiedzialności, więc wprowadzanie nowej klasy i dziedziczenia tylko dlatego, że zmieniła się jedna z odpowiedzialności jest błędem projektowania obiektowego. Taki sposób rozumowania szybko doprowadzi do ekspolozji kombinatorycznej, gdzie każda zmiana logiki (oraz kombinacje tych zmian) zamieszczana jest w swojej klasie dziedziczącej. Strategia jest jednym rozwiązań. A jeżeli nie chcemy wprowadzać strategii, to już na prawdę lepszy będzie serwis liczący koszt na podstawie getterów z OrderItem. Dobry kod proceduralny jest zawsze lepszy od słabego kodu obiektowego!

2. Wołanie super wersji metody z nadklasy jest tak zwany smrodkiem (code smell). Skoro nadpisuję metodę to jest już nieważna. Generalnie wskazuje to na słaby design.



Kolejna rzecz na jaką należy uważać to rozdział poświęcony "konfliktowi" pomiędzy Domain Driven Design a SOA.

Niestety muszę powiedzieć, że konflikt ten jest pozorny i wynika z niezrozumienia architektury aplikacji dla systemów, w których stosujemy DDD.
Autor we wcześniejszych rozdziałach promował swój pomysł pod tytułem Gateway i ten styl przeniósł na implementację DDD.
Nigdy nie "publikujemy" Modelu Domeny jako "API". Wiąże się z wieloma przykrymi konsekwencjami, ale tutaj odsyłam do Evansa. Model domenowy przykrywamy właśnie procedurami w stylu SOA - po prostu podstawowy pattern DDD: warstwa Serwisów Aplikacyjnych. I po problemie:)
Było to powiedziane już 5 lat temu: DDD the opposite of SOA? Uh, no.

//========================================

Polecam rozdział pod tytułem "Retired Patterns" przypomina nam jak smutne i przykre bywało drzewiej programowanie w EE:)

Ktoś sprzątać musi aby bałaganić mógł ktoś

Wszyscy zapewne pamiętamy burzliwą dyskusją Joela Spolskyego z Uncle Bobem (skrót na infoq)

Odbiła się ona szerokim echem dyskusji na ogólny temat: rzemiosło, profesja, jakość czy moźe lepiej byle jak, byle szybko, byle jako tako zadowolić klienta?

Kto ma rację?

Oczywiście ideałem byłoby dobrze i tanio. Ale jak intuicyjnie czujemy - tak to można tylko w mordę dostać;)

Prawda jak zwykle leży gdzieś po środku.

/*
 * W rozważaniach pomijam specyficzne przypadki typu
 * "firma nieustannie na dorobku"
 * albo specyficzny rodzaj dostawcy
 *
 * Zakładam, że bawimy się w projektach perspektywicznych
 * i jesteśmy świadomi zaciąganego kredytu bałaganu
 */


Ciekawą analizę tego zjawiska oraz racjonalne i pragmatyczne podejście do problemu przedstawił ostatnio w swojej genialnej (i jak zwykle niemiłosiernie ospałej) prezentacji sam guru DDD: Errrrrric Evaaaaans: Strategic Design - Responsibility Traps.

Poruszana tematyka zaczyna być omawiana od 30. minuty, ale gorąco wszystkich zachęcam do obejrzenia całości. Evans po mistrzowsku (i z typowym dla siebie poczuciem humoru) buduje od początku kontekst aby w 30. minucie wygarnąć nam co o nas myśli.
Wcześniej dowiecie się min. jakich strategicznych błędów nie popełniać podczas modernizacji systemu. Okazuje się, że standardowe 3 podejścia są z góry skazane na porażkę.

Prezentacja jest wg. mnie tak dobra, że w moim rankingu zajmuje miejsce 2. - zmieniając tym samym ostatnie notowania.


ZAŁOŻENIA (SAD BUT TRUE)
System jako całość nie może być dobrze przemyślany i zaprojektowany. KROPKA.
Nigdy nie będzie dostatecznie dużo: czasu, pieniędzy, wiedzy biznesowej, ludzi z odpowiednimi kwalifikacjami, czasu, pieniędzy, czasu, pieniędzy, czasu, pieniędzy,...

CO Z TEGO WYNIKA
Mamy 2 możliwości:
a) Wszystko zrobić "byle jak"
b) Pewną część zrobić porządnie i zgodnie z zasadami sztuki (oczywiście kosztem tego, że pozostała część będzie jakości mniejszej niż w punkcie a). W którą część i dlaczego warto zainwestować wysiłek - dowiemy się już za chwilę.

PROBLEM
Evans wytyka często spotykany problem. Ja nazwałbym go "złym rozłożeniem potencjału".
Evans opisuje taki oto często powtarzający się wzorzec: najlepsi (w sensie doświadczenia, intuicji, smaku a nie np certyfikatów) programiści/projektanci/architekci zajmują się tworzeniem tak zwanej "platformy". W zależności od systemu może to być wewnętrzny framework, główne biblioteki - ogólnie najczęściej są to jakieś zawiłości techniczne.

Natomiast reszta teamu - radośni hakierzy odpowiadają zwykle za dostarczanie corowych ficzerów biznesowych budowanych na bazie tejże tworzonej przez lokalnych guru platformy. Oczywiście ficzerów okraszonych zaokrąglonymi rogami w GUI - zgodnie z najnowszą modą żadna kanciasta forma nie jest dozwolona;)

Dostarczają oni funkcjonalności nazwanych przez Evansa sexy capabilities. Robią to tak jak potrafią, czyli byle jak byle szybko:)

Klient jest oczywiście zachwycony nowymi seksownymi możliwościami i nie zważa na marudzenie "nudziarzy od platformy", którzy narzekają, że znowu muszą sprzątać. Zresztą... po co sprzątać skoro działa?
Hero of the day to ten, kto zrobił zaokrąglony guzik zwiększający obroty o 1%;)

Oczywiście przyrost bałaganu jest większy niż możliwości jego sprzątania i mamy problem...

ROZWIĄZANIE: DESTYLACJA
Kto jak kto, ale my Słowianie mamy doświadczenie w destylacji więc mógłbym sobie odpuścić ten rozdział;)




Pomysł Evansa polega na wydestylowaniu domeny corowej. Zacznijmy od tego, że Evans wyróżnia 3 klasy domen:

- Core Domain - są to te specyficzne aspekty biznesu, będące powodem dla którego w ogóle warto tworzyć system. Przykładowo to one warunkują przewagę klienta nad konkurencją, lub odróżniają go od innych. To właśnie w tym miejscu mieszkają "sexy capabilities".

I to właśnie w ten kawałek (a powinien być relatywnie mały) inwestujemy największy wysiłek umysłowy.

To tutaj jest miejsce dla całej artylerii sprawdzonych technik naszego rzemiosła: szczegółowa analiza, archetypy biznesowe, wzorce projektowe, narzut na hermetyzację domeny, narzut na otwartość na rozbudowę, narzut na testability...

Core powinien być dobrze uniezależniony od pozostałych domen, które z definicji są w jakimś sensie "mniej godne zaufania" (bo np niestabilne).

- Supporting Domain - dodatkowe ficzery, bez których jednak można się obyć. Ten kawałek systemu może nawet np outsourceować. Jego jakość z założenia może być niska.

- Generic Domain - specyficzne domeny typu podsystem fakturowania lub biblioteka do operowania na grafach. Najlepiej kupić/uzyć gotowe rozwiązanie. Pamiętając o unikaniu zależności ze strony Core Domain.


Dobrym przykładem ilustrującym relatywizm tego pojęcia w zależności do biznesu jest system komentarzy użytkowników wystawianych kontrahentom.
W ebay jest to corowa funkcja (bez niej nikt nie kupiłby niczego od nieznajomej osoby). Dla amazona to po prostu jakiś poboczny ficzer (supportig domain) - ludzie i tak kupią jeżeli czegoś potrzebują lub po prostu mają ochotę.

Pamiętajmy, że developerzy nie są w stanie (ba, nie powinni) określić co należy a co nie do Core Domain w konkretnym przypadku danego klienta. Określenie Core Domain to jedna z głównych rzeczy, którą trzeba z niego wydusić;)




Chyba już domyślacie się jakie rozwiązanie sugeruje Evans...
Core Team zajmuje się Core Domain.
Najważniejsza część systemu ma szansę być zrobiona zgodnie ze sztuką a członkowie tego teamu zyskują uznanie jako dostawcy "sexy capabilities":)


Mam nadzieję, że moja recenzja/streszczenie zachęci Was (a szczególnie managerów) do poświęcenia godziny cennego czasu na prezentację Evansa.
Ciekaw jestem co sądzicie na temat tego podejścia - liczę na dyskusję równie owocną jak ta z przedostatniego posta:)

//==============================

Prowokacyjnie dodam, że Joel Spolsky stosuje jednak strategię "klasyczną". Flagowe oprogramowanie w ofercie firmy Joela: Copilot (soft dla helpdesku pozwalający na zdalną pracę na maszynie "petenta") to nic innego jak nakładka na OpenSourceowy projekt na licencji GPL ;PPP

Czyli ni mniej ni więcej: ktoś zrobił platformę a partacze Joela dodali "sexy capabilities" - a biznes chyba się kręci:)



I jeszcze druga myśl, która mi się nasunęła: Nierzadko występują takie przypadki, gdy naprawdę doświadczony developer w ogóle nie interesuje się pewną domeną biznesową. Po prostu uważamy (niebezpodstawnie) za interesują mniej więcej w takim samym stopniu jak zeszłoroczny śnieg. Wolimy zamiast tego skupić się na rozwoju w kierunku technicznym z uwagi na jego ogólność wynikającą z abstrakcyjności. Nic na siłę, każdy powinien znaleźć sobie optymalne zainteresowania...

Dzień bloggera

Ktoś sobie wymyślił, że dzisiaj będzie światowy dzień blogerów. Ok, fajnie.

Aby jakoś uczcić ten niezwykły, magiczny i jedyny w roku dzień postanowiłem zarekomendować nowego bloga poświęconego Javie i IT ogólnie: Technology For Human

Co prawda z założenia blog ma zawierać solidne tutoriale dla początkujących, ale na ile znam autora, to nawet doświadczeni wyjadacze będą mogli dowiedzieć się czegoś nowego z każdego posta.

Autor postawił sobie za cel przekaz rzetelnej wiedzy popartej realistycznymi przykładami. Bez ściemy znanej z tandetnych tutoriali. Autor zapewnia, że przykłady będą pochodzić z placu boju.

//==============================

Przyznam się, że sam miałem kiedyś w planie serię postów na temat własnej "skrzynki z narzędziami" - czyli kilku różnych kompletnych zestawów narzędzi developerskich oraz frameworków, które wykorzystałbym w przypadku problemu danej klasy. Niestety z braku czasu wciąż odkładam to zadanie. Ale na szczęście pojawiła się blog kolegi więc chyba sobie odpuszczę:)

Hasło na zakończenie tego magicznego i jedynego w roku dnia: Blog to zdrowie (a oto dowody tej tezy)

Stare Chińskie przysłowie: Jest czas na pracę i jest czas na zbieranie ryżu

Podobno to Hindusi odkryli system dziesiętny - Arabowie jedynie go rozpowszechnili (mając silne argumenty w dłoniach;).
Nieco mniej chlubnym osiągnięciem indyjskiej myśli jest na przykład biblioteka tagów JSP do integracji z JPA, na którą to niedawno przypadkiem się natknąłem. Zdaje się, że przyświeca jej motto "because we can!"

Stereotyp programisty Hindusa, który "nakłada gacie przez głowę" jest dosyć mocno rozpowszechniony i zakorzeniony ale wystrzegajmy się pychy.

Ciekawe studium hinduskiej mentalności znajdziemy w interesującej, lekkiej ale bardzo pouczającej książce Moja Praca Emigruje do Indii - A wszystko, co dostałem, to ta marna książka. Ale to tylko jeden z aspektów. Poznamy przede wszystkim globalne mechanizmy korporacyjne mające wpływ na niemal każdego z branży IT.

Chad Fowler zabiera nas w egotyczną podróż do Bangladuru, gdzie spędził 1.5 roku tworząc Software House dla jednej z amerykańskich korporacji.

Poznamy szereg kuriozów:
- na ogłoszenie o pracę odpowiada średnio kilkanaście tysięcy chętnych
- a mimo niemałego budżetu nie można sobie pozwolić na tych doświadczonych
- taksówkarz zna 5 języków
- a programista nie ma własnego komputera w domu

Każdy z 52 zgrabnych i wyważonych rozdziałów niesie w sobie pewien morał. Lokalny folklor jest jedynie pretekstem do przekazania metafory lub przesłania. Dostajemy zestaw gotowych strategii, uwag, ostrzeżeń i porad z zakresu szeroko pojętego samorozwoju i autopromocji. Kto się nie rozwija ten się cofa a zmiany są nieuniknione.

//=========================

Wymowa książki w naszym lokalnym kontekście nabiera jednak drugiego dna. Nie musimy obawiać się emigracji naszej pracy do Indii. Być może jesteśmy Indiami Europy:P

Po czym poznac, że jesteś zbyt stary na SCJP?

Skończyłem właśnie czytać miłą książeczkę SCJP Sun Certified Programmer i chciałem się podzielić przemyśleniami (bo tak se czasem lubię trochę pomyśleć).

Optymistycznie nastroił mnie do niej fakt iż jej autorzy są współautorami lekkiej i przyjemniej (jednocześnie bardzo pouczającej) książeczki Head First Design Patterns - którą to na marginesie szczerze polecam. Jej komiksowa forma i humor osadzony w latach '50 może wydawać się dziecinna ale po przeczytaniu wstępu wszystko stanie się jasne - jeden z autorów zajmuje się neuropsychologią i kognitywistyką więc dobrze wiej jak powinno się uczyć dorosłych ludzi.

Z dorosłymi idzie ciężej niż z dziećmi bo zazwyczaj myślą samodzielnie - a czasem nawet krytycznie.


No ale wracając do SCJP... Do samej książki nic nie mam - autorzy starali się jak mogli aby czerstwy temat przedstawić w miarę przystępny sposób. Pozytywne są komentarze typu: "my jako autorzy mamy na ten temat inne zdanie, ale na potrzeby egzaminu musisz robić tak i tak". Każdy z 10 rozdziałów obejmuje pewne zagadnienie - na dosyć podstawowym poziomie, ale mimo tego czasem można dowiedzieć się czegoś nowego. Na zakończenie każdego z rozdziałów mamy pytania sprawdzające, które z założenia odpowiadają tym z właściwego egzaminu. Utrzymane są głównie w konwencji: masz tu kawałek "super-profesjonalnego" kodu, skompiluj w jednej półkuli mózgu i ew. uruchom w drugiej; możesz też jęknąć w razie wyjątku. Problem merytoryczny jest zwykle banalny a wręcz wypaczony, natomiast cały ciężar trudności leży po stronie składni upstrzonej kuriozalnymi identyfikatorami i perfidnych zagrywek służących odwróceniu uwagi.

Zacząłem się zastanawiać dla kogo i po co jest ten egzamin... Doszedłem do wniosku, że możesz być na niego zbyt stary gdy masz niektóre z poniższych objawów:

• Zastanawiasz się gdzie są pogrubienia slow kluczowych - a nie ma...:P będziemy bawić się w sado-maso
  
• Zastanawiasz się gdzie jest cholerny kompilator i podkreślenia błędów?!? - a nie ma...:P i nie będzie...:P już wiesz na czym ma polegać cała ta żałosna zabawa...
  
• Zaczynasz się czuć jak student I roku na jakimś bezsensownym egzaminie z twierdzeń i ich dowodów
  
• #$%^& idę pograć sobie na PS3
  
• Zastanawiasz się gdzie jest dekiel który napisał ten kod? Tak się przecież nie programuje nawet w PHP w gimnazjum! Niech bym go tylko dostał w swoje ręce.
  
• Zwolnic go natychmiast i zanotować nazwisko na liście ludzi, z którymi nigdy nie chcesz współpracować
  
• Co to w ogóle za odpowiedź "G) Compilation fails"? To po cholerę komitujesz mi do poważnego testu niekompilujący się kod baranie jeden! W chyba każdej firmie dostałbyś po premii (a w pożądaj poleciałbyś na pysk) za choćby parę takich smrodków!
  
• Tijaaa znowu pytanie z serii "wlałeś benzynę przez rurę wydechową. Co się stanie? Samochód pojedzie ale skręci w drzewo. Samochód nie odpali. Samochód wybuchnie." Nie wydurniaj się człowieku. No wlej tą benzynę jak biały człowiek do baku i nie zawracaj mi głowy zgadywanką co się stanie jak dodatkowo założsysz gacie przez głowę.
  
• Zaczynasz rozumieć pojęcie "Code made in India"
  
• Gryzie Cię poczucie tracenia czasu
  
• Obawiasz się, ze jeszcze jeden rozdział i nabawisz się autyzmu
  
• Zaczynasz żałować, ze nie masz tego autyzmu - wspaniałego schorzenia, które pozwala skupiać się godzinami na nieistotnych pierdołach i ignorować szerszy kontekst
  
• Boisz się, ze nabyty autyzm mogą odziedziczyć Twoje dzieci (ku chwale wujka Suna)
  
• Motyla noga! Gdybym był wzrokowcem a nie słuchowcem to może przynajmniej widziałbym te brakujące średniczki i nawiasiki:/
  
• Dowiadujesz się, ze o wiele ważniejsze od projektowania i rozmyślania nad architekturą jest znajomość kolejności operatorów (nawiasy są dla cieniasów)
  
• Dowiadujesz się, że enkapsulacja to jednak prywatne pola i publiczne gettery/settery
  
• Dowiadujesz się, że w programowaniu współbieżnym najważniejsze jest kretyńskie zaprojektowanie wątków oraz to aby całość jakimś cudem się skompilowała. Teoria współbieżności jest dla dinozaurów programujących w ADA.
  
• Zastanawiasz się jak mogłeś przez 6 lat programować w języku, którego jak się okazuje w ogóle nie znasz
  

//=====================

Jest tez druga strona medalu: możesz być zbyt młody na SCJP... Jeżeli dopiero zaczynasz przygodę z Javą to olej certyfikaty ciepłym moczem parabolicznym. Ciesz się życiem i programowaniem. Programowanie wcale nie musi być nudnym zajęciem polegającym na wyszukiwaniu literówek i analizowaniu jakiegoś gównianego kodu (no dobra, czasem jest). W tej zabawie chodzi na prawdę o coś zupełnie innego!

A jeżeli chcesz zwiększyć swojego skilla to przeczytaj sobie dwie doskonale książki:
- Efektywne programowanie w języku Java autorstwa samego Joshua Bloch - projektanta i autora dużej części klas biblioteki standardowej Java; książka o której to sam James Gosling powiedział, ze gdyby została napisane wcześniej to inaczej zaprojektowałby Javę;)
- Java. Potrzaski zestaw 50 na prawdę realistycznych i ważnych haczyków na które należy uważać (nie ma tam syfu typu brak średnika)

Jeżeli jeszcze Ci mało, to proszę:
- More Java pitfalls - druga część potrzasków
- interesuje cię programowanie współbieżne? bardzo dobra pozycja: Java. Współbieżność dla praktyków

Ucz się z tych pozycji, ale powtarzam: nie trać czasu na certyfikat! To w żaden sposób nie zrobi z Ciebie lepszego człowieka (ani programisty).

Później przyjdzie czas na ważniejsze zagadnienia: projektowanie (wzorce projektowe), architektura, analiza itd... Nie zapominaj też o takich "szczegółach" jak dogadywanie się z ludźmi (koledzy z teamu, klient). A średniki poprawia Eclipse;P

Bo najważniejsza jest odpowiedzialność Synu...

...najbardziej trafną metaforą obiektów programistycznych jest organizm biologiczny. Podobnie jak komórki, obiekty "nie wiedzą", co dzieje się wewnątrz innych obiektów, ale komunikują się z nimi realizując bardziej złożone cele. W przeciwieństwie do takiego organizmu program monolityczny przypomina mechanizm zegarka, zawierający nieprzeliczalną (sic!) liczbę trybików. Trybiki nie mają żadnej inteligencji i są bezużyteczne poza mechanizmem, w którym pracują. Taki projekt nie ma szans powodzenia. Budując mechanizmy zegarowe, dochodzisz w końcu do takiej złożoności, że całość przestaje funkcjonować.

Heh czyli powiedzenie "działa jak w zegarku" nie jest komplementem lecz inwektywą:P

Cytat pochodzi z książki Projektowanie obiektowe - Role, odpowiedzialność i współpraca autorstwa Rebeki Wirfs-Brock i Alana McKean, którą to chciałbym w niniejszym poście zarekomendować.

/*
A na marginesie przypomnę, że Rebeka jest autorką ciekawej prezentacji krytykującej podejście do projektu polegające na rozpoczynaniu od zaprojektowania bazy danych - życia nie oszukasz.
*/

Na wstępie uprzedzam iż książka jest mocno abstrakcyjna a miejscami wręcz filozoficzna - raczej nie przypadnie do gustu tym, który idą z duchem czasu - czasu napier....

Książka Rebeki i Alana wprowadza nas w świat Responsibilty-Driven Design. Świat, w którym posłujemy się bytami o ściśle określonych rolach. Nie ma w nim miejsca na radosną twórczość, boskie klasy o wszechmocnej odpowiedzialności i tony spaghetti kodu. RDD z założenia ma na celu uporządkowanie chaosu i przygotowanie się na przyszłą i nieuniknioną ewolucję systemu.

W jaki sposób? O tym właśnie traktuje cała książka. Natomiast w skrócie sposób zasadza się na świadomym i konsekwentnym przypisywaniu tytułowych ról, odpowiedzialności i współpracy.

Czym jest współpraca i odpowiedzialność - myślę, że wszyscy intuicyjnie wiemy. Zasady GRASP są jasne w tych kwestiach:
- współpraca - utrzymujmy jak najmniej powiązań (Low coupling)
- odpowiedzialność - im niej tym lepiej (najlepiej niech klasa ma jedną odpowiedzialność) - w skrócie: dążymy do wysokiej kohezji klasy.


Natomiast tytułowe role to nic innego jak pewne zakresy odpowiedzialności. W RDD nie bawimy się już radośnie definiując na chybił trafił klasy a w nich metody (najlepiej statyczne hehe) typu załatwZprawę() albo zróbDobrze(). Nie, w ten sposób daleko nie zajdziemy - co najwyżej do wersji 1.0. W RDD myślimy nie na poziomie klasek ale na poziomie bytów pewnych typów zajmujących się ściśle pewnymi odpowiedzialnościami.

W RDD wyróżniamy zestaw głównych stereotypów ról, które mogą być grane przez nasze obiekty:

• magazyn informacji (information holder) - przechowuje i dostarcza informacje
  
• łącznik (structurer) - utrzymuje relację pomiędzy obiektami oraz informacje o tych relacjach
  
• dostawca usług (service provider) - wykonuje zadania oraz, w ogólności, oferuje usługi obliczeniowe
  
• koordynator (coordinator) - obsługuje zdarzenia przez przekazywanie zadań do innych obiektów
  
• kontroler (controller) - podejmuje decyzje i bezpośrednio kieruje zadaniami innych obiektów
  
• transformator (interfacer) - przekształca informacje i żądania pomiędzy różnymi częściami systemu

Role, odpowiedzialności i współpraca są głównym tematem książki lecz nie jedynym. Właściwie to są osią wokół której pojawiają się konteksty inny problemów projektowych, takich jak: style architektoniczne, elastyczność, analiza obiektowa, style obsługi błędów...

Można oczywiście zadać sobie pytanie: co mnie obchodzi jakiś RDD? To pewnie kolejna ściema dzięki której ktoś miał temat na książkę, kilka prezentacji w fajnych hotelach, temat na blogaska i oczywiście... źródło łatwych dochodów;P

Wg mnie warto jednak zastanowić się nad paroma koncepcjami zawartymi w RDD ponieważ wydają się one być uogólnieniem Domain Driven Design. W DDD mamy building blocks (o których już pisałem) służące do modelowania dziedziny: encje, VO, agregaty, polityki, servisy, repo i fabryki.

RDD unosi problem standardowych artefaktów na nieco wyższy poziom abstrakcji. Wspomniane stereotypy ról pokrywają building block z DDD. Ale stereotypy ról nie ograniczają się jedynie do klocków służących do modelowania dziedziny. Standardowe role pokrywają cały system - nie tylko warstwę biznesową.

//======================

A co by było gdyby język wspierał role na poziomie składni;)))? Gdyby zamiast public class TaxService{} deklarować public service Tax{} albo z innej beczki: public coordinatror EventManager{}. Wówczas może kompilator mógłby jakoś magicznie sprawdzać czy klasa nie robi tego co do niej nie należy i chronić zbyt cwanego programistę przed stworzeniem Potwora Spaghetti:)

Eeee... chyba wczorajsza dawka strawy z nadmierną ilością ryb i niedostatkiem wieprza, do której mój prasłowiański żołądek nie jest przystosowany, skutkuje dzisiejszym majaczeniem;)
Przecież na początek wystarczyłyby adnotacje w jakimś nowym, pięknym frameworku:)

Książka nad książkami

Gdyby co dziesiąty programista ją przeczytał to świat byłby lepszy...

Mam na myśli "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development" autorstwa Craiga Larmana (amazon).

Książka wpadła mi w ręce (właściwie to na dysk;) już jakiś czas temu, ale niedawny zakup papierowej wersji nakłonił mnie do zareklamowania jej każdemu kto ma tyle wolnego czasu aby tu zajrzeć;)

Tytuł jest mylący - można by z niego wywnioskować, że jest to kolejna książka prezentująca kilka wzorców na nudnych czy kuriozalnych przykładach (do tego jeszcze w UMLu zamiast w Javie).
Nic bardziej mylnego proszę Państwa! Larman zastosował prastary indiański chłyt marketingowy - bo jak powszechnie wiadomo wszystko co ma w tytule "wzorzec projektowy" sprzedaje się lepiej od tego co nie ma w tytule tego chwytliwego zwrotu (choćby był to podręcznik do HTMLa;).

Tak na prawdę książka jest poświęcona zagadnieniu Unified Process - wszelkie skojarzenia z RUP są jak najbardziej zdrowe. Po prostu chłopaki z Rationala wzięli sobie czysty i piękny byt myślowy, dobździali do tego kawał autystycznego kombajnu i tony szablonów dokumentów, których i tak nikt nie czyta;P

Larman prezentuje nam proces wytwarzania oprogramowania... Właściwie to prowadzi nas za rękę przez jego kolejne fazy - gdyż jest to oczywiście proces iteracyjny.

Natomiast rzekomi bohaterowie książki pełnią tak na prawdę następujące role:
- UML - jest scenografią
- Wzorce projektowe - są niczym starożytny grecki chór budzący sumienie projektantów gdy zastanawiają się czy i tym razem nie wystarczyłoby prymitywne i prostackie rozwiązanie (no i oczywiście są wspomnianym chwytem marketingowym).

Na tym tle rozgrywają się dwa dramaty (żeby już tak po całości pojechać Antykiem), czyli dwa przykładowe systemy, których wytworzenie jest naszym zadaniem:
- jeden z nich to typowy nudny system korporacyjny - innymi słowy to na co jesteśmy skazani w codziennej pracy zawodowej (tu przestroga do studentów: zmieńcie sobie kierunek studiów póki nie jest jeszcze za późno;)
- drugi to komputerowa reifikacja gry Monopoly - przynajmniej jakaś odmiana:)

Zatem mamy dwa totalnie odmienne problemy i jeden spójny sposób (proces) na ich wytworzenie...

Pokrótce:
Najpierw zapoznajemy się z filozofią iteracyjności (chyba nie ma takiego słowa, bo spellcheck mi to podkreśla;), ewolucyjności i zwinności.
Następnie po zapoznaniu się z dwoma problemami przechodzi do fazy wstępnej w której należy określić wizję projektu, określamy krytyczne wymagania i juzkejsy.

W pierwszej (już właściwej) fazie pracujemy nad modelem domeny, pilnujemy się aby iteracyjne wprowadzać wymagania (nie robimy wszystkiego na raz, bo wyjdzie nam wodospad, czyli projekt skończy w szambie), poznajemy GRASP i wiele innych rzeczy...

W drugiej fazie uszczegóławiamy analizę i poznajemy podstawowe wzorce projektowe.

W fazie trzeciej nowe wymagania (ooo projekt jest otwarty na rozbudowę - jak fajnie), nowe wzorce...

To tylko wyrywkowe zagadnienia - książka liczy 700 stron więc nie ma sensu jej streszczać.


Unified Process nie jest akademickim toczeniem kręgla. Ta metodyka jest ekstremalnie pragmatyczna. Nie tracimy czasu na produkowanie ton dokumentów, których nikt nie czyta!

Larman wskazuje nam, które artefakty (diagramy, dokumenty, kod, testy) są istotne i jasno tłumaczy DLACZEGO są istotne - nie pozostawia tu żadnych wątpliwości.

W skrócie: Larman prezentuje nam spojrzenie z różnych poziomów abstrakcji (przyznam, że mi jako programiście szeroko otworzyło to oczy)
- analityk biznesowy - zostawia po sobie dokument wizji, wymagania
- analityk systemowy - zostawia po sobie model domenowy, juzkejsy, sekwencje procesów biznesowych
- architekt - zostawia po sobie architekturę (niespodzianka) - w dużym skrócie styl projektowania
- projektant - zostawia po sobie diagramy: klas i oczywiście diagramy dynamiczne (tworzone na podstawie wzorców)
- programista - zostawia po sobie kod i testy
Artefakty wyjściowe z jednego poziomu abstrakcji są artefaktami wejściowymi do następnego.

heh... porównajmy sobie to ze znanym nam procesem "chałupniczo garażowym" gdzie mamy jedną warstwę abstrakcji:
- programista - zostawia po sobie bajzel:)

//=============================

Podsumowując chcę gorąco zachęć do lektury... Larman ma niesamowity umysł charakteryzujący się klarownością myśli i wypowiedzi - co widać w strukturze i stylu książki oraz posiada rzadką zdolność do syntetyzowania wiedzy z bardzo szerokiego zakresu. Osobiście to właśnie cenię najbardziej - raczej zdolność do syntezy niż analizy (chociaż ta też się przydaje;).