20. Шаблон High Cohesion.

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

High Cohesion твердит, что класс должен стараться выполнять как можно меньше не специфичных для него задач, и иметь вполне определенную область применения. Только с опытом приходит понимание балансировки между High Cohesion и Low Coupling. считается что связывание и зацепление это инь и янь проектирования ПО. Некорректное связывание порождает неправильное зацепление и наоборот.

21. Шаблон Controller.

Контроллер берёт на себя ответственность за выполнение операций, приходящих от пользователя и часто выполняет сценарий одного или нескольких вариантов использования (например, один контроллер может обрабатывать сценарии создания и удаления пользователя). Как правило, контроллер не выполняет работу самостоятельно, а делегирует обязанности компетентным объектам.

Иногда класс-контроллер представляет всю систему в целом, корневой объект, устройство или важную подсистему (внешний контроллер).

22. Шаблон Polymorphism.

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

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

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

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

Альтернативные варианты поведения на основе типа. Условная передача управления - это основная отличительная особенность любой программы. Если программа разработана с использованием if-then-else или условных операторов по ключу, то при добавлении новых вариантов поведения приходится модифицировать логику условных операторов. Такой подход затрудняет процесс модификации программ в соответствии с новыми вариантами поведения, поскольку изменения приходится вносить сразу в нескольких местах программного кода - там, где используются условные операторы.

Подключаемые программные компоненты. Если рассматривать компоненты с точки зрения отношения клиент/сервер, то как можно заменить один серверный компонент другим, не затрагивая при этом клиентские компоненты?

Обсуждение. Если обязанности в системе распределены на основе шаблона Полиморфизм, то такую систему можно легко модифицировать, добавляя все новые вариации.

Предостережение.

Иногда разработчики злоупотребляют добавлением интерфейсов и применением принципа полиморфизма с целью обеспечения дееспособности системы в неизвестных заранее новых ситуациях. Если точка вариации известна и обоснована, если существует высокая вероятность вариативного поведения, то такие усилия вполне оправданы. Реально оценивайте вероятность вариативного поведения.

Преимущества.

• Впоследствии можно легко расширять систему, добавляя новые вариации.

• Новые вариации можно вводить без модификации клиентской части приложения.