GRASP: принцип High Cohesion.

Проблема. Как обеспечить возможность управления сложностью?

Решение. Распределение обязанностей, поддерживающее высокую степень зацепления.

Зацепление (cohesion) (или более точно, функциональное зацепление) — это мера связанности и «сфокусированности» обязанностей класса.

Считается что элемент обладает высокой степенью зацепления, если его обязанности тесно связаны между собой и он не выполняет огромных объемов работы. В качестве элемента может выступать класс, подсистема и т. п.

Класс с низкой степенью зацепления выполняет много разнородных функций или несвязанных между собой обязанностей. Такие классы создавать нежелательно, поскольку они приводят к возникновению следующих проблем:

· трудность понимания;

· сложность при повторном использовании;

· сложность поддержки;

· надежность, постоянная подверженность изменениям.

Классы со слабым зацеплением, как правило, являются слишком «абстрактными» или выполняют обязанности, которые можно легко распределить между другими объектами.

Пример. Рассмотрим тот же пример, что и для Low Coupling.

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

Для создания экземпляра объекта Payment можно использовать объект

Register. Тогда экземпляр объекта Register сможет отправить сообщение addPayment объекту Sale, передавая в качестве параметра новый экземпляр объекта Payment (рис. 1).

При таком распределении обязанностей платежи выполняет объект Register, т.е. объект Register частично несет ответственность за выполнение системной операции makePayment. В данном обособленном примере это приемлемо. Однако если и далее возлагать на класс Register обязанности по выполнению все новых и новых функций, связанных с другими системными операциями, то этот класс будет слишком перегружен и будет обладать низкой степенью зацепления.

Предположим, приложение должно выполнять пятьдесят системных операций и все они возложены на класс Register. Если этот объект будет выполнять все операции, то он станет чрезмерно «раздутым» и не будет обладать свойством зацепления. И дело не в том, что одна задача создания экземпляра объекта Payment сама по себе снизила степень зацепления объекта Register; она является частью общей картины распределения обязанностей.

На рис. 2 представлен другой вариант распределения обязанностей. Здесь функция создания экземпляра платежа делегирована объекту Sale. Благодаря этому поддерживается более высокая степень зацепления объекта Register. Поскольку такой вариант распределения обязанностей обеспечивает низкий уровень связывания и более высокую степень зацепления, он является более предпочтительным.

На практике уровень зацепления не рассматривают изолированно от других обязанностей и принципов, обеспечиваемых шаблонами Expert и Low Coupling.

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

Несколько сценариев, иллюстрирующих различную степень функционального зацепления.

1) Очень слабое зацепление. Только один класс отвечает за выполнение множества операций в самых различных функциональных областях. Допустим, существует класс RDB-RPC-Interface, полностью отвечающий за взаимодействие между реляционными БД и вызов удаленных процедур. Это две абсолютно разные функциональные области.

2) Слабое зацепление. Класс несет единоличную ответственность за выполнение сложной задачи из одной функциональной области. Допустим, некий класс RDBInterface полностью отвечает за взаимодействие с реляционными БД. Методы класса связаны между собой однако их слишком много, и их реализация требует огромных объемов кодов. Таких методов может быть несколько сотен или больше. Данный класс следует разделить на несколько более мелких классов.

3) Среднее зацепление. Класс имеет несложные обязанности в нескольких различных областях, логически связанных с концепцией этого класса, но не связанных между собой. Допустим существует класс Company, который несет полную ответственность за знание всех сотрудников компании и всю финансовую информацию. Эти две области не слишком связаны между собой, однако логически связаны понятием «компания». К тому же предполагается, что такой класс содержит небольшое количество открытых методов и требует незначительных объемов кода для их реализации.

4) Сильное зацепление. Класс имеет среднее количество обязанностей из одной функциональной области и для выполнения своих задач взаимодействует с другими классами. Допустим некоторый класс RDBInterface лишь частично отвечает за взаимодействие с реляционными БД. Для извлечения и хранения объектов в БД он взаимодействует с с десятком других классов.

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

Шаблон High Cohesion, как и другие понятия объектно-ориентированной технологии проектирования, имеет аналогию в реальном мире. Всем известно, что человек, выполняющий большое число разнородных обязанностей (особенно тех, которые можно легко распределить между другими людьми), работает не очень эффективно. Это касается менеджеров, которые не умеют распределять обязанности между своими подчиненными. Такие люди страдают от «низкой степени зацепления» и могут легко «расклеиться». Понятия Low Coupling и High Cohesion являются взаимозависимыми.

Некорректное связывание порождает неправильное зацепление, и наоборот. Предположим, например, что класс уровня пользовательского интерфейса, представляющий окно, сохраняет данные в БД  и вызывает удаленные службы. Такой класс не только обладает слабым зацеплением, но и оказывается сильно связанным со многими другими элементами.