- •Проектирование информационных систем
- •Вопрос 1. Обязанности, методы, взаимодействия
- •Вопрос 2. Шаблоны
- •Information Expert
- •Шаблон Information Expert
- •Шаблон Creator
- •Шаблон Low Coupling
- •Шаблон High Cohesion
- •Шаблон Controller
- •Вопрос 3. Реализация прецедентов
- •Пример: Реализация прецедентов для данной итерации разработки pos системы тт
- •Проектное решение: makeNewSale
- •Выбор класса-контроллера
- •Проектное решение: enterItem
- •Проектное решение: endSale
- •Проектное решение: makePayment
- •Проектное решение: startup
- •Проектное решение: store-create
- •Подключение уровня интерфейса пользователя к уровню предметной области
Шаблон 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, как и другие понятия объектно-ориентированной технологии проектирования, имеет аналогию в реальном мире. Всем известно, что человек, выполняющий большое число разнородных обязанностей (особенно тех, которые можно легко распределить между другими людьми), работает не очень эффективно. Это касается менеджеров, которые не умеют распределять обязанности между своими подчиненными. Такие люди страдают от "низкой степени зацепления" и могут легко "расклеиться".