GRASP

GRASP (англ. general responsibility assignment software patterns — общие шаблоны распределения ответственностей; также существует английское слово "grasp" — «контроль, хватка») — шаблоны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению ответственностей классам и объектам.

GRASP принципы

GRASP - general responsibility assignment software patterns — общие шаблоны распределения ответственностей. GRASP шаблоны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению ответственностей классам и объектам.

Существует девять GRAPS шаблонов, изначально описанных в книге Крейга Лармана «Применение UML и шаблонов проектирования». В отличие от классических читателю паттернов из Банды Четырех, GRAPS паттерны не имеют выраженной структуры, четкой области применения и конкретной решаемой проблемы, а лишь представляют собой обобщенные подходы/рекомендации/принципы, используемые при проектировании дизайна системы.

GRASP состоит из 5 основных и 4 дополнительных шаблонов.

Основные шаблоны:

• Information Expert

• Creator

• Controller

• Low Coupling

• High Cohesion

Дополнительные шаблоны:

• Pure Fabrication

• Indirection

• Polymorphism

• Protected Variations

Информационный эксперт (Information Expert)

Шаблон определяет базовый принцип распределения ответственности:

Ответственность должна быть назначена тому, кто владеет максимумом необходимой информации для исполнения — информационному эксперту.

Этот шаблон — самый очевидный и важный из девяти. Если его не учесть — получится "спагетти-код", в котором трудно разобраться.

Применение шаблона информационный эксперт повышает связность модулей и не противоречит свойству инкапсуляции.

В следующем примере на C# класс Customer содержит ссылки на все заказы клиентов, следовательно логично разместить тут метод для подсчета общей стоимости заказов:

 public class Customer
    {
        private readonly List<Order> _orders = new List<Order>();

        public decimal GetTotalAmount(Guid orderId)
        {
            return this._orders.Sum(x => x.Amount);
        }
    }

Name: Information Expert Problem: What is a basic principle by which to assign responsibilities to objects? Solution: Assign a responsibility to the class that has the information needed to fulfill it.

Создатель (Creator)

Creator или Создатель — суть ответственности такого объекта в том, что он создает другие объекты. Сразу напрашивается аналогия с абстрактной фабрикой.

По сути шаблон проектирования Абстрактная фабрика (создание объектов концентрируется в отдельном классе) это альтернатива создателя.

Но есть ряд моментов, которые должны выполняться, когда мы наделяем объект ответственностью создателя:

• Создатель содержит или агрегирует создаваемые объекты;

• Создатель использует создаваемые объекты ;

• Создатель знает, как проинициализировать создаваемый объект ;

• Создатель записывает создаваемые объекты

• Создатель имеет данные инициализации для A

Возвращаясь к примеру с Customer'ом, рассмотрим следующий .NET код:

public class Customer
    {
        private readonly List<Order> _orders = new List<Order>();

        public void AddOrder(List<OrderProduct> orderProducts)
        {
            var order = new Order(orderProducts); // создатель
            _orders.Add(order);
        }
    }

Name: Creator Problem: Who creates an A? Solution: Assign class B the responsibility to create an instance of class A if one of these is true:

• B contains or compositely aggregate instances of A

• B records instances of A

• B closely use instances of A

• B has the initializing information for instances of A

Consistent with LRG and the Creator solution, the Board will create Squares.

Controller

Шаблон сontroller призван решить проблему разделения интерфейса и логики в интерактивном приложении. Это не что иное, как хорошо известный контроллер из MVC парадигмы. Контролер отвечает за обработку запросов и решает кому должен делегировать запросы на выполнение. Если обобщить назначение сontroller, то он должен отвечать за обработку входных системных сообщений.

Подробнее про контроллер можно почитать в статье: MV-паттерны для проектирования веб-приложений

Name: Controller Problem: What first beyond the UI layer receives and coordinates a system operation? Solution: Assign the responsibility to an object representing one of the following:

• Represents the overall "system", a "root object", a device that the software is running within, or a major subsystem

• Represents a use case scenario within which the system operation occurs

Слабая связанность (зацепление) или Low Coupling

Если объекты в приложении сильно связанны, то любой их изменение приводит к изменениям во всех связанных объектах. А это неудобно и порождает множество проблем. Low coupling как раз говорит о том что необходимо, чтобы код был слабо связан и зависел только от абстракций. Слабая связанность так же встречается в SOLID принципах как The Dependency Inversion Principle​ (DIP) и слабая связанность по сути это реализация Dependency Injection принципа. Когда мы уходим от конкретных реализаций и абстрагируемся на уровнях интерфейсов(которые легко подменять нужными нам реализациями), тогда код не завязан на определенные реализации.

Name: Low Coupling Problem: How to reduce the impact of change? Solution: Assign responsibilities so that unnecessary coupling remains low. Use this principle to evaluate alternatives.

Высокая связанность (High Cohesion)

По сути High Cohesion очень тесно связанна с Single Responsibility Principle​ (SRP) с SOLID принципов. High Cohesion получается в результате соблюдения SRP.

High Cohesion принцип говорит о том, что класс должен стараться выполнять как можно меньше не специфичных для него задач, и иметь вполне определенную область применения. Только с опытом приходит понимание балансировки между High Cohesion и Low Coupling. считается что Low Coupling и High Cohesion) это инь и янь проектирования ПО. Некорректное юзание High Cohesion порождает неправильное Low Coupling и наоборот.

Name: High Cohesion Problem: How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling? Solution: Assign responsibilities so that cohesion remains high. Use this to evaluate alternatives.

Чистая выдумка (Pure Fabrication)

Pure Fabrication или чистая выдумка, или чистое синтезирование. Здесь суть в выдуманном объекте. Аналогом может быть шаблон Service (сервис) в парадигме DDD.

In the contexts of software architecture, service-orientation and service-oriented architecture, the term service refers to a software functionality or a set of software functionalities (such as the retrieval of specified information or the execution of a set of operations) with a purpose that different clients can reuse for different purposes, together with the policies that should control its usage (based on the identity of the client requesting the service, for example).

Какую проблему решает Pure Fabrication?

• Уменьшает зацепление ( Low Coupling);

• Повышает связанность (High Cohesion) ;

• Упрощает повторное использование кода.

Не совсем понятно?

Давайте рассмотрим пример и все станет на свои места ^_^

К примеру у вас есть объект Customer и следую шаблону информационный эксперт вы наделили его логикой которую мы показывали выше, как вы реализуете сохранение Customera в БД?

Так вот следуя Pure Fabrication принципу, мы создадим Сервис или репозиторий который будет доставать и сохранять такой объект в базу данных.

Посредник (Indirection)

Indirection или посредник. Можно столкнуться с таким вопросом: «Как определить ответственность объекта и избежать сильной связанности между объектами, даже если один класс нуждается в функционале (сервисах), который предоставляет другой класс?»

Решение: возложите ответственность на промежуточный объект, чтобы он осуществлял связь между другими компонентами или службами, чтобы они не были напрямую связаны. Такое решение можно сделать с помощью GoF паттерна медиатор

К примеру у нас был код:

 public class CustomerOrdersController : Controller
    {
        private readonly IOrdersService _ordersService;

        public CustomerOrdersController(IOrdersService ordersService)
        {
            this._ordersService = ordersService;
        }
    }

мы можем переписать этот код с помощью mediator для связки между объектами:

public class CustomerOrdersController : Controller
{
	private readonly IMediator _mediator;

	public CustomerOrdersController(IMediator mediator)
	{
		this._mediator = mediator;
	}

	public async Task<IActionResult> AddCustomerOrder(
		[FromRoute]Guid customerId, 
		[FromBody]CustomerOrderRequest request)
	{
	   await _mediator.Send(new AddCustomerOrderCommand(customerId, request.Products));

	   return Created(string.Empty, null);
	}
}

Обратите внимание. Посредник поддерживает "low coupling", но снижает читабельность и понимание всей системы. Вы не знаете, какой класс обрабатывает команду из определения Controller. Это компромисс.

Полиморфизм (Polymorphism)

Полиморфизм позволяет реализовывать одноименные публичные методы, позволяя различным классам выполнять различные действия при одном и том же вызове. То есть объекты классов Square и Circle могут отображаться(реализовывать метод render) по разному несмотря не то, что они оба подклассы Shape, метод render определен в Shape. (Overriding).

Принцип полиморфизма является основополагающим в ООП. В этом контексте принцип тесно связан с GoF паттерном strategy. Это самый яркий пример реализации полиморфизма.

Устойчивость к изменениям (Protected Variations)

Проблема: Как спроектировать объекты, подсистемы и системы таким образом, чтобы изменения или нестабильность этих элементов не оказывали нежелательного влияния на другие элементы?

Решение: Определите точки прогнозируемого изменения или нестабильности, распределите обязанности по созданию стабильного интерфейса вокруг них.

По мнению многих это самый важный принцип который косвенно связан с остальными принципами GRASP. В настоящее время одним из наиболее важных показателей качества кода является простота изменений. Как архитекторы и программисты, мы должны быть готовы к постоянно меняющимся требованиям. Это не является «nice to have» атрибутом - это «must-have» в любом приложении и наша обязанность как программистов и архитекторов нашей системы это обеспечить.

Useful links

• https://www.youtube.com/watch?v=Kp1nfw0LDXc