GRASP Patterns

В сущности GRASP - это строительные блоки, на основе которых построены GOF паттерны, хотя GRASP и были выведены позже. Они заполнили пустоту между принципами OOP и паттернами GOF.

Patterns list:

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

1. Information expert

    Частный случай принципа "Low Coupling".
   
    Проблема
    В системе должна аккумулироваться, рассчитываться и т. п. необходимая информация.
   
    Решение
    Назначить обязанность аккумуляции информации, расчёта и т. п. классу (информационному эксперту), обладающему необходимой информацией.
   
    Рекомендации
    Информационным экспертом может быть не один класс, а несколько.
   
    Пояснение
    Информация должна обрабатываться там, где она есть.

    

2. Creator

    Проблема
    "Кто" должен отвечать за создание экземпляра класса.
   
    Решение
    Назначить классу B обязанность создавать объекты другого класса A.
   
    Рекомендации
    Логично использовать паттерн если класс B содержит, агрегирует, активно использует и т. п. объекты класса A.
   
    Пояснение
    Создавать класс должен тот, кому он нужен.

    

3. Controller

    Проблема
    "Кто" должен отвечать за обработку входных системных событий?
   
    Решение
    Обязанности по обработке системных сообщений делегируются специальному классу. Контроллер - это объект, который отвечает ха обработку системных событий и не относиться к интерфейсу пользователя. Контроллер определяет методы выполнения системных операций.
   
    Рекомендации
    Для различных прецедентов логично использовать разные контроллеры (контроллеры прецедентов) - контроллеры не должны быть перегружены. Внешний контроллер представляет всю систему целиком, его можно использовать, если он будет не слишком перегруженным (то есть, если существует лишь несколько системных событий).
   
    Пояснение
    Централизованная обработка запросов к системе. Пример: превращение асинхронных запросов от UI к домену (бизнес логике) в синхронные.

    

4. Low Coupling

    Проблема
    Обеспечить низкую связанность про создании экземпляра класса и связывании его с другим классом.
   
    Решение
    Распределить обязанности между объектами так, чтобы степень связанности оставалась низкой.
   
    Пояснение
    Если в системе есть несколько объектов, то связи между ними должны быть минимальны.
    Для уменьшения влияния изменения одной части системы на другую. Такую систему легче декомпозировать.

    

5. High Cohesion

    Проблема
    Необходимо обеспечить выполнение объектами разнородных функций.
   
    Решение
    Обеспечить распределение обязанностей с высоким зацеплением.
   
    Пояснение
    Все методы в классе должны быть логически "зацеплены" (относиться к одному и тому же). Класс должен иметь одно назначение.

    

6. Polymorphism

    Проблема
    • Как обрабатывать альтернативные варианты поведения на основе типа?
    • Как заменять подключаемые компоненты системы?
   
    Решение
    • Обязанности распределяются для различных вариантов поведения с помощью полиморфных операций этого класса.
    • Каждая внешняя система имеет свой интерфейс.
   
    Пояснение
    Применимо для расширения функциональности системы без переписывания кода (например система плагинов).

    

7. Pure Fabrication

    Проблема
    Какой класс должен обеспечивать реализацию паттернов "Low Coupling", и "High Cohesion"?
   
    Решение
    Присвоить группу обязанностей с высокой степенью зацепления классу, который не представляет конкретного понятия из предметной области (синтезировать искусственную сущность для обеспечения высокого зацепления и слабого связывания).
   
    Пояснение
    Когда в предметной области не существует объекта, который необходим для соблюдения 2х выше указанных принципов, создаётся искусственный объект.
    Пример 1 - постоянное хранилище чего либо с методами для добавления и обновления элементов.
    Пример 2 - facade.

    

8. Indirection

    Проблема
    Как перераспределить обязанности объектов, чтобы обеспечить отсутствие прямого связывания?
   
    Решение
    Присвоить обязанности по обеспечению связи между службами или компонентами промежуточному объекту.
   
    Пояснение
    Зависимость на интерфейсах.

 

9. Protected Variations

    Проблема
    Как спроектировать систему так, чтобы изменение одних её элементов не влияло на другие?
   
    Решение
    Идентифицировать точки возможных изменений или неустойчивости и распределить обязанности таким образом, чтобы обеспечить устойчивую работу системы.
   
    Пояснение
    Использование всех выше перечисленных принципов.  

---

 Source [video]