Образец «High Cohesion»

Проблема:

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

Решение:

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

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

Пример:

Используем тот же пример, что и для предыдущего образца (см. рис. 4.13). Согласно образцу «High Cohesion», наилучшим ре­шением также является вариант 2, поскольку при этом класс RegistrationController делегирует обязанность создания нового объекта класса Shedule классу Student, и у самого класса RegistrationController будет на одну обязанность меньше (т.е. его сцепление будет сильнее).

Следствия:

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

Образец High Cohesion, как и другие понятия объектно-ори­ентированной технологии проектирования, имеет аналогию в ре­альном мире. Известно, что человек, выполняющий большое число разнородных обязанностей (особенно тех, которые можно легко распределить между другими людьми), работает не очень эффективно. Особенно это касается менеджеров, которые не умеют распределять обязанности между своими подчиненными.

Слабая связанность и сильное сцепление — основные прин­ципы проектирования ПО. Объектное проектирование пол­ностью с ними согласуется, поскольку одним из его базовых принципов является модульность.

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

Набор обязанностей классов, полученный в результате их распределения, должен быть проанализирован на предмет выяв­ления и устранения следующих проблем:

· дублирования одинаковых обязанностей в различных классах;

· противоречивых обязанностей в рамках класса;

· классов с одной обязанностью или вообще без обязанностей;

· классов, взаимодействующих с большим количеством дру­гих классов.