Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
2 семестр ЗО / Лаб.работы / ЛабРаб № 10!.doc
Скачиваний:
56
Добавлен:
06.02.2016
Размер:
697.86 Кб
Скачать

Шаблон High Cohesion

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

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

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

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

  • Трудность понимания.

  • Сложности при повторном использовании.

  • Сложности поддержки.

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

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

Пример. Для анализа шаблонаHighCohesionможно использовать тот же пример, что и дляLowCoupling.

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

Какой класс должен выполнять эту обязанность?

По­скольку в реальной предметной области сведения о платежах записываются в реестре, согласно шаблону Creator, для создания экземпляра объектаPaymentможно использовать объектRegister. Тогда экземпляр объектаRegisterсмо­жет отправить сообщениеaddPaymentобъектуSale, передавая в качестве пара­метра новый экземпляр объектаPayment, как показано на рис. 2.10:

Рисунок 2.10 – Экземпляр объекта Registerсоздает объектPayment

При таком распределении обязанностей платежи выполняет объект Register, т.е. объектRegisterчастично несет ответственность за выполнение сис­темной операцииmakePayment.

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

Предположим, приложение должно выполнять пятьдесят системных опера­ций и все они возложены на классRegister. Если этот объект будет выполнять все операции, то он станет чрезмерно "раздутым" и не будет обладать свойством зацепления.

На рис. 2.11 представлен другой вариант распределения обязанностей.

Рисунок 2.11 – Объект Saleсоздает экземп­ляр объектаPayment

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

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

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

Соседние файлы в папке Лаб.работы