Tym przewrotnym tytułem chcę dziś zwrócić uwagę na dwa ważne i bardzo pomocne wzorce analityczne (słowo analityczne ode mnie, w książkach na temat wzorców bardzo rzadko używana jest nazwa „wzorce analityczne”) opisane w książce M.Fowlera. Wzorcami analitycznymi nazywam te wzorce projektowe, które pomagają w analizie i projektowaniu modelu dziedziny systemu (biznesowy model obiektowy).
Polecam oczywiście lekturę całej książki Martina Fowlera Architektura Systemów Zarządzania Przedsiębiorstwem Wzorce Projektowe.
Mamy model czegoś co ma się wydarzyć. Na tym etapie kompletnie nie ma sensu zajmowanie się tym ile znaków ma nazwisko. To może się zmienić w toku analizy a nawet implementacji, ale nie powinna ulec zmianie logika tej operacji.
Jak już opanujemy logikę (zrozumiemy co i jak ma działać i zaprojektujemy jak to zrealizować) zabieramy się za szczegóły. Model dziedziny (fragment):
Jak widać, np. danePasażera jako zawartość to daneOsoby a nie „pola i typy danych”. Czym są DaneOsoby znajdziemy tu:
Zamiast prostych typów danych (np. znakowe) stosujemy obiekt jako typ danych. To znakomicie ułatwia późniejsze rozszerzenia i zmiany (nie musimy nic zmieniać w modelu dziedziny by np. dodać drugie imię do danych osoby, modyfikujemy w jednym miejscu jedynie deklarację klasy DaneOsoby).
Wywołanie operacji podajDaneBiletu zwraca obiekt DaneBiletuLitniczego (lub agregat zawierający wszystkie bilety):
Nie jest to ten sam obiekt co wcześniej, ValueObject to typ danych, Transfer Object to serializacja, której celem jest jedynie przeniesienie w możliwie najprostszy do odczytania sposób określonych informacji (oba te obiekty nie mają jednak tożsamości). Nie należy tych wzorców mylić ani utożsamiać, gdyż Value Object to „typ danych” zaś Transfer Object to jedynie parametr wywołań, Value Object powinien mieć operacje sparwdzajace jego poprawność (walidacja), Transfer Object służy wyłącznie do przekazywania informacji jako parametr wywołań i odpowiedzi (w pewnym sensie definiuje protokół wymiany danych).
Korzyści ze stosowania tych wzorców to między innymi:
- szczegóły danych odkładamy na koniec projektu co jest bezpieczne (nie musimy modyfikować projektu w miarę postępu pozyskiwania wiedzy o szczegółach),
- zmiana tych szczegółów nie spowoduje potrzeby zmiany szkieletu modelu dziedziny,
- możemy prowadzić spokojną uporządkowaną analizę „top-down” (od ogółu do szczegółu),
- możemy się umówić z developerem, że jako analitycy nie będziemy wnikali w szczegóły danych, nadal możemy operować klasami ValueObject i TransferObject (klasy te będą w początkowej fazie projektu bez atrybutów),
- mimo to możemy umieścić w klasach ValueObject warunki walidacji (operacje klas, których tu nie pokazywałem) i do tego one między innymi służą (to się nazywa określanie wymagań poprzez testy czyli TDD),
- już na samym początku możemy uzgodnić postać danych wymienianych na interfejsach (np. zdalna komunikacja) i korzystać z tej umowy.
Tak zaprojektowany system spełnia także jedną z kluczowych zasad projektowania obiektowego: „system jest zamknięty na zmiany i otwarty na rozszerzenia”.
Na zakończenie
Często słyszę, że to trudne i pracochłonne (dodatkowe klasy w modelu), niestety zbyt prosty projekt potrafi być kosztowniejszy w rozbudowie w porównaniu z pierwotnym wytworzeniem, dlatego jak klient w ramach wymagań wpisuje (a wpisuje coraz częściej): system ma umożliwiać łatwe rozszerzenia funkcjonalności, to należy go tak projektować, w przeciwnym wypadku wymaganie to nie jest spełnione…
Druga uwaga: często sami klienci zabijają swoje projekty żądając na samym początku udokumentowania wszystkich szczegółów jakie im do głowy przyjdą nie potrafiąc jednocześnie opisać mechanizmu działania ich organizacji (lub nowego pomysłu). To niestety często spotykane zjawisko, z którym moim zdaniem należy walczyć. Paradoksalnie złożoność systemów biznesowych tkwi w mechanizmie ich funkcjonowania a nie w danych, które zbierają (których nie raz jest po prostu za dużo…).
Dane to fakty jakie chcemy znać, te fakty są konsekwencją działania a nie odwrotnie.
Na rynku w Polsce są jeszcze między innymi książki o wzorcach:
- Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku Autorzy: Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides
- J2EE. Wzorce projektowe. Wydanie 2, Autorzy: Deepak Alur, John Crupi, Dan Malksarchitektura MVC). Druga to w zasadzie dokumentacja [[J2EE]]. Tak więc obie raczej dla programistów i architektów. Książkę Fowlera polecam analitykom i architektom także. Wszystkim polecam także UML i Wzorce projektowe Larmana.
(UWAGA! Pokazano projekt poglądowy, wyssany z palca, nie ujawniłem treści żadnego z moich realnych projektów).
Footnotes[1]M. Fowler, Architektura systemów zarządzania przedsiębiorstwem. Wzorce projektowe [na:] ?helion.pl?, http://helion.pl/ksiazki/architektura-systemow-zarzadzania-przedsiebiorstwem-wzorce-projektowe-martin-fowler,szabko.htm, udostępniono 16 lipiec 2017.[2]H. SA, J2EE. Wzorce projektowe. Wydanie 2 [na:] ?helion.pl?, http://helion.pl/ksiazki/j2ee-wzorce-projektowe-wydanie-2-deepak-alur-john-crupi-dan-malks,j2eew2.htm, udostępniono 16 lipiec 2017.Bibliografia
Fowler, M., Architektura systemów zarządzania przedsiębiorstwem. Wzorce projektowe [na:] ?helion.pl?, http://helion.pl/ksiazki/architektura-systemow-zarzadzania-przedsiebiorstwem-wzorce-projektowe-martin-fowler,szabko.htm, udostępniono 16 lipiec 2017.SA, H., J2EE. Wzorce projektowe. Wydanie 2 [na:] ?helion.pl?, http://helion.pl/ksiazki/j2ee-wzorce-projektowe-wydanie-2-deepak-alur-john-crupi-dan-malks,j2eew2.htm, udostępniono 16 lipiec 2017.
