CHWYT

W projektowaniu zorientowanym obiektowo GRASP to skrót od General Responsibility Assignment Software Patterns (Wzorce oprogramowania przypisania odpowiedzialności ogólnej ), akronim od „GRASP (projektowanie zorientowane obiektowo – wzorce oprogramowania przypisania odpowiedzialności ogólnej)”. Chociaż uważa się, że więcej niż wzorce per se, są to szereg „dobrych praktyk” zalecanych zastosowań w projektowaniu oprogramowania.

Ekspert informacyjny

Ekspert informacyjny GRASP to podstawowa zasada przypisania odpowiedzialności. Mówi nam na przykład, że odpowiedzialność za stworzenie obiektu lub implementację metody musi spaść na klasę, która zna wszystkie informacje potrzebne do jego stworzenia. W ten sposób uzyskamy projekt o większej spójności, a tym samym informacja pozostanie zamknięta (zmniejszone sprzężenie).

Problem: Jaka jest ogólna zasada przypisywania odpowiedzialności do obiektów?

Rozwiązanie: Przypisz odpowiedzialność ekspertowi ds. informacji.

Korzyści: Hermetyzacja jest utrzymywana, obiekty wykorzystują własne informacje do wykonywania swoich zadań. Zachowanie jest rozdzielone między klasy, które zawierają wymagane informacje. Są łatwiejsze do zrozumienia i utrzymania.

Twórca

Wzorzec twórcy pomaga nam określić, kto powinien być odpowiedzialny za tworzenie (lub tworzenie instancji ) nowych obiektów lub klas .

Nowa instancja powinna zostać utworzona przez klasę, która:

posiada informacje niezbędne do wykonania obiektu, lub
Użyj bezpośrednio utworzonych wystąpień obiektu lub
Przechowuje lub obsługuje wiele instancji klasy
Zawiera lub dodaje klasę.

Jedną z konsekwencji użycia tego wzorca jest widoczność pomiędzy utworzoną klasą a klasą twórcy. Jedną z zalet jest niskie sprzężenie, co oznacza łatwość konserwacji i ponownego użycia. Instancje to jedna z najczęstszych czynności w systemie obiektowym. W związku z tym warto mieć ogólną zasadę przypisywania odpowiedzialności za tworzenie. Dobrze odwzorowany projekt może obsługiwać luźne sprzężenie, zwiększoną przejrzystość, hermetyzację i ponowne wykorzystanie.

Kontroler

Wzorzec kontrolera to wzorzec, który służy jako pośrednik między pewnym interfejsem a implementującym go algorytmem, w taki sposób, że to on odbiera dane od użytkownika i ten, który wysyła je do różnych klas zgodnie z metoda o nazwie.

Ten wzorzec sugeruje, że należy oddzielić logikę biznesową od warstwy prezentacji, aby zwiększyć ponowne wykorzystanie kodu i jednocześnie mieć większą kontrolę.

Zaleca się dzielenie zdarzeń systemowych na jak największą liczbę kontrolerów w celu zwiększenia spójności i zmniejszenia sprzężenia.

Wysoka spójność i niskie sprzężenie

Koncepcje kohezji i sprzężenia nie są ze sobą ściśle powiązane, jednak zaleca się, aby mieć wyższy stopień kohezji przy niższym stopniu sprzężenia. W ten sposób zależność jest mniejsza, a cele każdego obiektu w systemie są określone.

Wysoka spójność

Mówi nam, że informacje przechowywane przez klasę muszą być spójne i muszą być (w miarę możliwości) powiązane z klasą.

Coincident Cohesion : Moduł wykonuje wiele zadań, bez żadnego związku między nimi.
Spójność logiczna : Moduł wykonuje wiele powiązanych ze sobą zadań, ale w czasie wykonywania tylko jedno z nich zostanie wykonane.
Spójność czasowa : Zadania realizowane przez moduł mają, jako jedyny związek, „że muszą być wykonywane w tym samym czasie”.
Spójność proceduralna : Jedyny związek między zadaniami modułu polega na tym, że odpowiadają one sekwencji kroków charakterystycznych dla „produktu”.
Spójność komunikacji : Zadania odpowiadają sekwencji kroków typowych dla „produktu” i wszystkie dotyczą tych samych danych.
Spójność informacji : Zadania realizowane przez moduł mają swój własny punkt wyjścia, niezależne kodowanie i pracę na tych samych danych. Typowy przykład: OBIEKTY
Spójność funkcjonalna : Kiedy moduł wykonuje jedno i tylko jedno zadanie, mając jeden cel do spełnienia, mówi się, że ma spójność funkcjonalną.

Niskie sprzęgło

Jest to idea, aby klasy były ze sobą jak najmniej powiązane. W taki sposób, aby w przypadku modyfikacji w którejkolwiek z nich, był jak najmniejszy wpływ na resztę klas, promując ponowne wykorzystanie i zmniejszając zależność między klasami.

Łączenie treści : gdy moduł bezpośrednio odwołuje się do treści innego modułu. (W językach wysokiego poziomu jest to bardzo rzadkie)
Wspólne sprzężenie : Gdy dwa moduły uzyskują dostęp (i wpływają) na tę samą wartość globalną.
Sprzężenie sterowania : Gdy moduł wysyła element sterujący do innego, który określa jego logikę wykonania.

Polimorfizm

Ilekroć musisz wykonać odpowiedzialność zależną od typu, musisz skorzystać z polimorfizmu , gdy alternatywy lub powiązane zachowania różnią się w zależności od typu (klasy), przypisz odpowiedzialność za zachowanie - za pomocą operacji polimorficznych - do typów, dla których zachowanie jest różne. Przypisz tę samą nazwę do usług na różnych obiektach.

Czysta produkcja

Czysta produkcja występuje w klasach, które nie reprezentują rzeczywistej jednostki lub obiektu w domenie problemu, ale są celowo tworzone w celu zmniejszenia sprzężenia, zwiększenia spójności i/lub usprawnienia ponownego wykorzystania kodu. Jest to rozwiązanie, gdy projektant natrafia na luźną klasę i nie ma innej klasy, w której mógłby zaimplementować jakieś metody. To znaczy, że jest to klasa „wynaleziona” lub że nie istnieje w problemie, ale przez dodanie jej system jest strukturalnie ulepszony. Jako przeciwwskazanie należy wspomnieć, że przy nadużywaniu tego wzorca zwykle pojawiają się klasy funkcji lub algorytmów (które mają tylko jedną metodę).

Pośredni

Wzorzec pośredni pozwala nam obniżyć sprzężenie między dwiema klasami poprzez przypisanie odpowiedzialności za mediację między nimi trzeciemu elementowi pośredniemu (klasie). Na przykład w POS (Point of Sale Terminal) użyj interfejsu „Adapter”, za pomocą którego z klas, które to wykonują, możemy ustalić różne metody płatności.

Problem: Gdzie przypisać obowiązki, aby uniknąć/ograniczyć bezpośrednie sprzężenie między elementami i poprawić ponowne wykorzystanie?
Rozwiązanie: Przypisz odpowiedzialność do obiektu, który pośredniczy między elementami.

Wariacje chronione

Jest to podstawowa zasada zabezpieczania się przed zmianą, w taki sposób, że wszystko, co przewidzieliśmy w poprzedniej analizie, które jest podatne na modyfikacje, owijamy w interfejs, wykorzystując polimorfizm do tworzenia kilku implementacji i pozwala na przyszłe wdrożenia, tak aby to, co pozostaje jak najmniej powiązane z naszym systemem, aby kiedy pojawia się zmienność, ma na nas jak najmniejszy wpływ. Jest to część zaawansowanych wzorców chwytania.