Поведенческие шаблоны проектирования

Шаблонный метод

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

"Шаблонный метод" определяет основной алгоритм и позволяет подклассам изменить некоторые шаги этого алгоритма без изменения его общей структуры.

Для применения этого шаблона необходимо исследовать общий алгоритм и определить, какие его шаги и стадии являются стандартными, то есть общими, а какие должны определяться подклассами в зависимости от условий конкретной задачи. Создается абстрактный базовый класс, в котором реализован принцип общности и определения стандартных шагов. Если для некоторых шагов требуются различные реализации, то определяются "замещающие" методы:

1. "Шаблонный метод" определяет "скелет" алгоритма.
2. "Абстрактный класс" определяет абстрактные операции, замещаемые в конкретных подклассах для реализации шагов алгоритма.
3. "Конкретный класс" реализует операции, выполняющие шаги алгоритма способом, который зависит от подкласса.
4. "Конкретный класс" предполагает, что инвариантные шаги алгоритма будут выполнены в "абстрактном классе".

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

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

Высокое зацепление

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

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

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

• Зацепление – мера связанности и сфокусированности обязанностей класса.

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

Реализация шаблона "Высокое зацепление" позволяет легко модифицировать и сопровождать программное обеспечение, повышает возможность его повторного использования.

Мера связности модулей определяется количеством информации, которой располагает один модуль о природе другого. В свою очередь, мера зацепления модуля определяется степенью сфокусированности его обязанностей.

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

Контроллер

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

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

"Контроллер"– это объект, который отвечает за обработку системных событий и не относится к интерфейсу пользователя. "Контроллер" определяет методы выполнения системных операций.

Паттерн "Контроллер" призван решить наболевшую проблему разделения интерфейса и логики в интерактивном приложении.

Если вспомнить изученный ранее архитектурный шаблон MVC, то шаблон проектирования "Контроллер" отвечает за организацию компоненты, скрывающейся под символом "С":

• Вызовы из слоя представления "V" передаются в контроллер "C".
• Контроллер, в зависимости от специфики данных и деталей их обработки, маршрутизирует вызовы определенной модели "M".

Системный компонент, реализуемый по шаблону "Контроллер", должен удовлетворять следующим условиям:

• Он должен представлять всю систему в целом, устройство или подсистему (внешний контроллер).
• Для всех системных событий в рамках экземпляра сценария прецедента должен использоваться один и тот же класс-контроллер.

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

Шаблон "Контроллер" является не объектом автоматизации предметной области, а искусственной конструкцией, которая выполняется в соответствии с четко определенными правилами.

"Контроллер" выполняет роль универсального и добросовестного постового, который следует общим правилам и не допускает возникновения заторов и пробок. Его задача –следить за выполнением установленного процесса и корректировать ход его исполнения в случаях, когда кто-то из участников дорожного движения вышел за рамки установленных правил.

Полиморфизм

Принцип полиморфизма является основополагающим для современной парадигмы объектно-ориентированного программирования. В контексте применения шаблонов проектирования паттерн "Полиморфизм" призван решать задачу обработки вариантов поведения системы на основе типа обрабатываемого сообщения или данных. Лучше всего эта задача решается с использованием полиморфных операций. Кроме того, при помощи шаблона "Полиморфизм" легко создавать подключаемые к системе компоненты. В итоге использование принципов полиморфизма позволяет получить следующие преимущества:

• Расширение и масштабирование существующей системы не составляет больших трудностей и затрат.
• Простота расширения системы за счет добавления новых вариаций.

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

Перенаправление

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

Наиболее очевидным вариантом является делегирование обязанности обеспечения связи между службами или компонентами специализированному промежуточному объекту. Рассматриваемый шаблон "Перенаправление" разработан для решения задачи прямой связности.

Паттерн реализует низкую связность между классами, путем назначения обязанностей по их взаимодействию дополнительному объекту – посреднику.

Заключение об поведенческих шаблонах

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

Поведенческие шаблоны, с точки зрения вклада в архитектурное проектирование, являются связующим звеном между структурными, порождающими и архитектурными, интеграционными шаблонами.

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

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