Шаблоны проектирования не в программировании (часть 2)
В предыдущей части мы рассмотрели паттерн "Низкая связанность (Low Coupling)", там был анонс паттерна "Высокое зацепление (High Cohesion)", о нём и поговорим сегодня.
Ссылка на первую часть "Низкая связанность (Low Coupling)"
Высокое зацепление (High Cohesion)
Классическое определение "высокого зацепления" - объект должен быть сфокусированным на выполнении группы связанных обязанностей. Не связанные обязанности должны быть переданы другим объектам. Обычно используется совместно с шаблоном Низкая связанность (Low Coupling).
Сфокусированность - определена предметная область, управляема и понятна.
Такое разграничение обязанностей между объектами упрощает поддержку при переиспользовании.
Использование паттерна в программировании
Классы должны содержать связанную бизнес — логику. Что значит что обязанности класса должны соответствовать каким-то требованиям.
Примеры распределения обязанностей:
* использование одной области данных,
* выполнение аналогичных функций,
* одновременное использование
и т.п.
Использование паттерна в анализе
При моделировании объектов распределять обязанности между ними по определённой бизнес-логике.
Пример, описанный выше, подходит и для этой ситуации.
Использование паттерна при формировании продукта
При формировании требований к продукту, тщательно отнестись к набору функций которые он выполняет. Продукт не должен содержать лишних функций не направленных на удовлетворение потребностей клиентов.
Недостатки
Руководствуясь только паттерном "Высокое зацепление", можно достигнуть такого распределения обязанностей, при котором взаимодействие между объектами будут не оптимальны, ресурсоёмки.
Идеал
Высокое зацепление и низкая связанность выступают как инь-янь, не позволяя объектам выполнять одну функцию и иметь множество связей, или иметь одни мультифункциональный объект.
Ссылка на сообщество:
Я совсем не разработчик и из того, что поняла: видимо тут речь про выделение общих требований и указание их в других требованиях. Ну и соответственно, при внесении изменений в общие требования все это добро должно обновиться во всех местах, где используется.
Еще мы как бы разработчикам "мягко" говорим про то, что необходимо предусмотреть такие связи при реализации.