GRASP
Odpowiedzialność
Wykonywania
akcji
tworzenia nowych obiektów
koordynacji
Wiedzy
o swoich danych
o innych obiektach, danych które obiekt może policzyć itd.
Controller pattern
Wejściowy obiekt operacji biznesowej (np. serwis aplikacyjny). Start obsługi akcji biznesowej.
Pierwszy obiekt pod warstwą UI
Np. serwis pobierający dane z repozytorium i delegujące je do agregatu gdzie dzieją się rzeczy
Creator pattern
Kto może tworzyć obiekty?
Obiekty X tworzą obiekty Y jeżeli:
X agreguje Y
X ściśle używa Y
X ma wszystkie dane do stworzenia Y
Indirection pattern (nie bezpośredniość)
Aplikacja nie musi wiedzieć w którą stronę przebiega bezpośrednie flow aplikacji.
W przykładzie występuje moduł przygotowania, który umożliwia działanie całej aplikacji, ale poszczególne metody o sobie nie wiedzą. Tutaj można użyć architektury typu mikro-jądro.
Związane wzorce projektowe
adapter
mediator
fasada
bridge
Information Expert ( Ekspert informacji)
Klasa eksperta dostaje najwięcej informacji, bo jej się to należy.
Przydziel odpowiedzialność obiektowi który ma najwięcej danych potrzebnych do wypełnienia zadania.
High Cohesion + Low Coupling
Polimorfizm
Dla różniących się zachowań, użyj polimorfizmu
Klient abstrakcji nie używa if-else
Klient nie sprawdza konkretnej implementacji
Chroniona zmienność
Ulotna logika musi być chroniona
Ukrywamy zmienne rzeczy
Enkapsulacja
Np. lista odcinków musi być ukryta pod klasą kursu, bo zasady mogą się zmienić wewnątrz
Pure fabrications
np. repozytorium
Sztuczny obiekt
Zwiększa kohezję
Zmniejsza coupling
np. Serwis domenowy
Pragmatyzm
Zawsze rób tak, żeby to miało sens ;)
Last updated
