Ооп Вместо Ооп: Grasp

GRASP — General Responsibility Assignment Software Patterns (базовые шаблоны распределения ответственности в программном обеспечении) Когда речь идет о термине «ООП», все наверняка имеют в виду объектно-ориентированное программирование, но сегодня мы не будем о нем говорить.
Почти.
Сегодня я хотел бы поговорить о принципах объектно-ориентированного проектирования, и в частности о паттернах GRAPS и их сфере применения.
GRASP состоит из 9 шаблонов:
Создатель

Контроллер

Чистое производство

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

Высокая сплоченность

Косвенность

Низкая связь

Полиморфизм

Защищенные варианты

Но сегодня будут рассмотрены не все, а только основные.
При этом хотелось бы добавить, что не все шаблоны являются «программными».
Некоторые из них (например, «Высокая сплоченность» и «Низкая связанность») являются принципами, а не примерами реализации.
Чем больше опыта у разработчика ПО, тем больше он понимает смысл предварительного проектирования и прототипирования и тем позже он приступает к непосредственно разработке системы, даже если это четырехтабличная база данных.
Это отражает его лень :) Ведь именно потому, что в нескольких предыдущих проектах на проектирование ушло слишком мало времени, в итоге система была переписана на 40-60%%, а среднемыслящий программист не любит делать то же самое это повторяется снова и снова, поэтому нам «приходится» уделять больше времени предварительному анализу.
И именно здесь он начинает интересоваться такими аспектами разработки программного обеспечения, как объектно-ориентированный анализ и проектирование.
Итак, поняв, что на моделирование нужно уделять больше времени, становится актуальным вопрос: «Ну а что тут проектировать, если и так все понятноЭ» В общем, если у вас за плечами достаточно большой груз знаний и опыта, и вам не приходилось сталкиваться с ООА/П, то все решения принимаются на уровне интуиции, а чтение литературы приводит лишь к систематизации знаний и, возможно, новые подходы.
Итак, со временем они открывают для себя GRASP. Как говорилось ранее, GRASP — это шаблоны проектирования.
А именно шаблоны, отвечающие за взаимосвязь объектов в системе.
Сколько раз вы задавались вопросом, где будет создан новый объект? В этом материале я хочу рассмотреть основные шаблоны GRAS (букву «P» опускаю во избежание тавтологии, так как в аббревиатуре она заменена на «шаблоны») на примере блога.

Создатель.

Как часто вы задавались вопросом, кто должен создать объект X? Они часто приходят к выводу, что объект необходимо создавать независимо от кого-либо; часто эта задача возлагается на объектное хранилище (класс коллекции), а иногда и на другие объекты системы.
Что правильно и какой вариант выбрать? Образец создатель сообщает нам, какие условия должны быть выполнены, чтобы объекты правильно генерировали друг друга.
Для этого существует несколько правил: объект А должен произвести объект Б, если:
объект A содержит или объединяет объекты B ^{(содержит либо свойство, либо коллекцию)}

объект А активно использует объекты Б ^{(основная часть работы с объектом Б происходит через объект А)}

объект A имеет данные инициализации для объекта B ^{(каждый раз при создании объекта B данные берутся из объекта A)}

Итак, глядя на диаграмму отношений, основанную на паттерне Creator, можно сделать вывод, что экземпляры класса Post должны создаваться внутри класса Blog, а Comments — внутри класса Post. Почему так, а не иначе? Например, почему нельзя создавать комментарии в блоге? Ну хотя бы потому, что это Пост содержит содержит экземпляры Comment, а Post также имеет информацию для создания экземпляра Comment (в нашем случае это просто указатель на родителя, но даже это не то, что имеет Blog по отношению к Comment).

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

Кому следует знать общее количество комментариев в блоге?

Пытаясь ответить на эти вопросы, нам необходимо определить, какие участники системы обладают необходимой информацией.
Таким образом, getCommentsCount() должен быть присвоен объекту Post, а объект Blog на основе промежуточных значений каждого из своих объектов Post получит общую сумму комментариев getTotalComments().

Но при этом именно Post должен отвечать за такие аспекты, как «получить заголовок поста» (getTitle()), «получить пост», «получить автора» и т.д.

Контроллер
Ну тут все просто.
Это не что иное, как C из аббревиатуры MVC :) Этот паттерн отвечает за то, кто именно должен совершать вызовы из V (View), и кому C должен делегировать запросы на выполнение (какая модель M должна их обрабатывать)

Низкая связь
Низкая связанность отвечает за то, чтобы объекты в системе знали друг о друге как можно меньше.
Ведь чем меньше объект знает о других объектах, тем более он будет изолирован и тем меньше правок потребуется вносить, если что-то изменится в системе.
На наших схемах все выглядит хорошо.
Блог ничего не знает о Comment, а степень связности каждого класса только одна.
В более сложных системах соединений гораздо больше, и шаблон «Низкая связь» позволяет избежать следующих проблем:
При внесении изменений в связанные классы необходимо вносить локальные изменения в этот класс.

Понимание каждого класса в отдельности становится более сложным и требует изучения всех связанных классов.

Повторное использование становится невозможным из-за того, что после выдергивания части системы приходится вытаскивать почти всю систему.

Высокая сплоченность
Высокая степень вовлеченности – именно так переводится название шаблона.
Это противовес предыдущей модели.
Вовлеченность — это процесс взаимодействия класса с другими классами системы и область ответственности за действия.
Давайте посмотрим на две диаграммы:

Как вы думаете, что правильнее? Отвечая на этот вопрос с точки зрения Low Coupling, во-первых, а так ли это хорошо, когда один класс отвечает и за измерение температуры за окном, и за движение метро, и за вычисление числа Пи до 87342 десятичных знаков? Вот почему Высокая сплоченность настаивает на том, чтобы класс старался выполнять как можно меньше неспецифических задач и имел очень конкретную сферу деятельности.
Только с опытом приходит понимание баланса между этими двумя паттернами.
Все.
На первое время хватит :) Если статья будет успешной, обещаю рассказать о некоторых других паттернах GRASP, а также паттернах GoF и многом другом из мира ООА/ООП.
оригинальная статья в моем блоге