GRASP jest zbiorem zasad, podobnie jak SOLID, z tą różnicą, że jest umocowany poziom wyżej (albo jeszcze wyżej). Postanowiłem się zmierzyć z zasadami GRASP na podstawie trzech artykułów (linki na końcu). Zasady te opisałem tak jak ja je rozumiem na podstawie własnych doświadczeń, więc nie koniecznie ktoś będzie się z tym zgadzał. Brak zgody to dobry powód do dyskusji .

Należy wspomnieć, że w DNA jeden z odcinków ósmego modułu, poświęcony jest zasadą  GRASP (moduł ósmy Modularyzacja).

W pierwszej wersji tego posta nie odniosłem się do opisu w DNA. Poprawiłem to i zamieściłem w nie których zasadach porównanie z DNA. Nie wszystkie zasady tego wymagają.

  1. Information Expert
  2. Creator
  3. Controler
  4. Low Coupling
  5. High Cohesion
  6. Polymorphism
  7. Pure Fabrication
  8. Indirection
  9. Protected Variations

1. Klasa i  jej odpowiedzialność (Infromation Expert).

Ta zasada przypomina mi pierwszą zasadę solid czyli pojedynczą odpowiedzialność, tylko według zasad GRASP to klasa powinna mieć taką wiedzę (odpowiedzialność) żeby bez pobierania danych z zewnątrz mogła realizować powierzone jej zadanie. Co może się kłócić z zasadą SRP czyli pojedyncza odpowiedzialność.  Czyli jak dla mnie zasada na poziomie architektury, nie koniecznie klasy.

2. Twórca (Creator)

Czyli jak dobrze stworzyć obiekt klasy, poprzez inną klasę, żeby uniknąć zbyt dużej ilości powiązań (częsty problem u mnie). Problem może jednak wynikać z braku trafnego zrozumienia domeny.

3.Kontroler (Controler)

Wiedząc, że MVC i kontroler tego wzorca jest dokładnym odwzorowaniem tej zasady, stwierdzam, że w moim przypadku poszedłem trochę dalej niż tylko kontroler jako warstwa pomiędzy widokiem, a modelem. Ja doszedłem do wniosku, że kontroler powinien być zbiorem interfejsów, które wywołują jakieś metody i bardziej wygląda jak sito przepuszczające dokładnie to co trzeba i nic po za tym.

W DNA zasada ta odnosi się do bytu poniżej controlera z MVC, gdyż controler z MVC jest traktowany jako część interfejsu użytkownika (UI).

4. Niska ilość Powiązań (Low Coupling)

Klasa  powinna mieć najmniej zależności, czyli nie robię klasy od wszystkiego tudzież klasy zbierającej w sobie wiele zależności.

5. Wysoka spójność (High Cohesion)

Klasa powinna być skupiona wokół wykonywania jednego zadania, podobnie jak zasada SRP.

6.Polimorfizm

Różne zachowanie obiektów. Dla przykładu zastępowanie instrukcji warunkowych zmianą zachowania obiektu.

7.Czysta produkcja (Pure Fabrication)

Ta zasada nie jest dla mnie do końca zrozumiała. Jest rozwiązaniem problemu sprzeczności powyższych zasad. Nie potrafię jej porównać z moimi doświadczeniami.

W DNA jest ta zasada wytłumaczona jako stworzenie obiektu pośredniego, który uzupełni funkcjonalność istniejącej klasy o funkcjonalność, którą nie chcemy w klasie trzymać.  Przykładzie podana była klasa w której nie chcemy trzymać funkcjonalności umożliwiającej zapis do bazy. Funkcjonalność tą przenosimy do repozytorium.

8.Pośrednictwo (Indirection)

Stworzenie warstwy pośredniczącej między klasami, w postaci interfejsów, klas abstrakcyjnych, fasad.

W DNA przetłumaczone jako Niebezpośredniość, po za tym pokrywa się z moim zrozumieniem, jest rozszerzone o wzorce jak fasada , adapter, bridge, mediator.

9.Zapewniona zmienność (Protected Variations)

Rób tak żeby system był podatny na zmiany. Czyli wiele zasad w jednym miejscu, a szczególnie istotne, żeby mieć interfejsy (na poziomie klasy) i moduły (na poziomie architektury).

10.Pragmatyzm, zasada dołożona w DNA, ja w skrócie opisał bym to jako zdrowy rozsądek.

 

Podsumowanie

Uważam, że na pewnym poziomie aplikacji nie ma łatwych zasad. Zasady są proste w teorii, w praktyce okazuje się, że problemem jest zaimplementowaniem nawet najprostszych z nich.

Pokuszę się o stwierdzenie, że łatwość implementacji zasad i wzorców jest proporcjonalna do poznania problemu z jakim się mierzymy. Im bardziej rozumiemy problem tym łatwiej nam się implementuje różne zasady.

W szkoleniu DNA  nie które z tych zasad ,takie jak Coupling i Cohesion, mają bardziej szczegółowy opis, ja przedstawiłem w najbardziej skróconej formie, w takiej jak ja to „ogarniam”. Do dokładnego opisu odysłam do DNA.

P.S.Szukam teraz różnych zasad, gdyż męczę się z refaktoryzacją systemu. Starego systemu, który ja kiedyś współtworzyłem i wiem, że popełniłem w nim wiele błędów. Teraz wiem jak ważne są te zasady i warto nie tylko je znać ale przynajmniej w jakimś stopniu (byle jak największym) implementować.

Źródła:

 

Kategorie: Inne