Погружение в паттерны проектирования (epub) - Погружение в паттерны проектирования 10343K (скачать epub) - Александр Швец Погружение в Паттерны Проектирования

v2018-1.5

Вместо копирайта

Привет! Меня зовут Александр Швец, я автор книги Погружения в Паттерны, а также онлайн курса Погружение в Рефакторинг.

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

Все деньги, вырученные с продаж моих книг и курсов, идут на развитие Refactoring.Guru. Каждая проданная копия приближает момент выхода новых курсов и книг. © Александр Швец, Refactoring.Guru, 2018 support@refactoring.guru

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

Содержание

Содержание Как читать эту книгу ВВЕДЕНИЕ В ООП Вспоминаем ООП Краеугольные камни ООП Отношения между объектами ОСНОВЫ ПАТТЕРНОВ Что такое паттерн? Зачем знать паттерны ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ Качества хорошей архитектуры Базовые принципы проектирования Инкапсулируйте то, что меняется Программируйте на уровне интерфейса Предпочитайте композицию наследованию Принципы SOLID S: Принцип единой ответственности O: Принцип открытости/закрытости L: Принцип подстановки Лисков I: Принцип разделения интерфейса D: Принцип инверсии зависимостей КАТАЛОГ ПАТТЕРНОВ Порождающие паттерны Фабричный метод Абстрактная фабрика Строитель Прототип Одиночка Структурные паттерны Адаптер Мост Компоновщик Декоратор Фасад Легковес Заместитель Поведенческие паттерны Цепочка обязанностей Команда Итератор Посредник Снимок Наблюдатель Состояние Стратегия Шаблонный метод Посетитель Заключение

Небольшой совет

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

Небольшой совет

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

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

Как читать эту книгу?

Эта книга состоит из описания 22-х классических паттернов проектирования, впервые открытых «Бандой Четырёх» ("Gang of Four" или просто GoF) в 1994 году.

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

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

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

Перед изучением паттернов вы можете освежить память, пройдясь по основным терминам объектного программирования. Паралельно я расскажу об UML-диаграммах, которых в этой книге огромное множество. Если вы уже всё это знаете — смело приступайте к изучению паттернов.

ВВЕДЕНИЕ В ООП

Вспоминаем ООП

Объектно-ориентированное программирование — это методология программирования, в которой все важные вещи представлены объектами, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.

Объекты, классы

Вы любите котиков? Надеюсь да, потому что я попытаюсь объяснить все эти вещи на примерах с котами.

Это UML-диаграмма класса. В книге будет много таких диаграмм.

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

Мурка, кошка вашей подруги, тоже является экземпляром класса Кот. Она имеет такой же набор поведений и свойств, что и Пушистик, а отличается от него лишь значениями этих свойств — она другого пола, имеет другой окрас, вес и т.д.

Объекты — это экземпляры классов.

Итак, класс — это своеобразный «чертёж», по которому строятся объекты — экземпляры этого класса.

Иерархии классов

Идём дальше. У вашего соседа есть собака Жучка. Как известно, и собаки, и коты имеют много общего — имя, пол, возраст, цвет есть не только у котов, но и у собак. Да и бегать, дышать, спать и есть могут не только коты. Получается, эти свойства и поведения присущи общему классу Животных.

UML-диаграмма иерархии классов. Все классы на этой диаграмме являются частью иерархии Животных.

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

Мы можем пойти дальше, и выделить ещё более общий класс живых Организмов, который будет родительским и для Животных, и для Рыб. Такую «пирамиду» классов обычно называют иерархией. Класс Котов унаследует всё как из Животных, так из Оганизмов.

Классы на UML-диаграмме можно упрощать, если важно показать отношения между ними.

Следует упомянуть, что подклассы могут переопределять поведение методов, которые им достались от суперкласса. При этом, они могут как полностью заменить поведение метода, так и просто добавить что-то к результату выполнения родительского метода.

Краеугольные камни ООП

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

Абстракция

Когда вы пишете программу, используя ООП, вы представляете её части через объекты реального мира. Но объекты в программе не повторяют в точности их реальные аналоги, да и это редко когда нужно. Вместо этого, объекты программы всего лишь моделируют поведение реальных объектов, важных в том или ином контексте, а остальные свойства реального объекта игнорируют.

Так, например, класс Самолёт будет актуален как для программы тренажёра пилотов, так и для программы бронирования авиабилетов, но в первом случае будут важны детали пилотирования самолёта, а во втором — лишь расположение и занятость мест внутри самолёта.

Разные модели одного и того же реального объекта.

Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали, не играющие существенной роли в данном контексте.

Инкапсуляция

Когда вы заводите автомобиль, вам достаточно повернуть ключи зажигания или нажать кнопку. Вам не нужно вручную соединять провода под капотом, поворачивать коленчатый вал и поршни, запуская такт двигателя. Все эти детали скрыты под капотом автомобиля. Вам доступен только простой интерфейс — кнопка зажигания, руль и педали. Таким образом, интерфейс — это публичная часть объекта, доступная остальным объектам.

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

Например, вы можете инкапсулировать что-то внутри класса, сделав его приватным (private) и скрыв доступ к этому полю или методу для объектов других классов. Более открытый режим видимости protected сделает это поле или метод доступным в подклассах.

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

Многих путает, что словом «интерфейс» называют и публичную часть объекта, и конструкцию interface из большинства языков программирования.

В объектном языке программирования, с помощью интерфейсов (обычно объявляемых через ключевое слово interface) можно явно описывать «контракты» взаимодействия объектов.

Например, вы создали интерфейс ЛетающийТранспорт с методом лететь(откуда, куда, пассажиры), а затем описали методы класса Аэропорта так, чтобы они принимали любые объекты с этим интерфейсом. Теперь вы можете быть уверены, что любой объект, реализующий интерфейс — будь то Самолёт, Вертолёт или ДрессированныйГрифон, сможет работать с Аэропортом.

UML-диаграмма реализации и использования интерфейса.

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

Наследование

Наследование — это возможность создание новых классов на основе существующих. Главная польза от наследования — повторное использование существующего кода. Расплата за наследование проявляется в том, что подклассы всегда следуют интерфейсу родительского класса. Вы не можете исключить из подкласса метод, объявленный в его родителе.

UML-диаграмма единичного наследования против реализации множества интерфейсов.

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

Полиморфизм

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

UML-диаграмма единичного наследования против реализации множества интерфейсов.

Теперь, представьте, что мы поместили нескольких собак и котов в здоровенный мешок. Затем, мы будем с закрытыми глазами вытаскивать их по одной из мешка. Вытянув зверушку, мы не знаем какого она класса. Но если её погладить, она точно издаст какой-то звук, зависящий от её класса.

bag = [new Cat(), new Dog()]; foreach (Animal a : bag)   a.makeSound()    // Meow! // Bark!

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

Полиморфизм — это способность программы выбирать различные реализации, при вызове операций с одним и тем же названием.

С другой стороны, полиморфизм — это способность объектов притворяться чем-то другим. В приведённом выше примере, собаки и коты «притворялись» абстрактными животными.

Отношения между объектами

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

Ассоциация в UML-диаграммах. Профессор взаимодействует со студентами.

Ассоциация — это когда один объект использует другой, либо зависит от него. В UML ассоциация обозначается простой стрелкой, которая направлена в сторону зависимости. Двустороння ассоциация между объектами вполне допустима.

Композиция в UML-диаграммах. Университет состоит из кафедр.

Композиция — это отношение «часть-целое» между двумя объектами, когда один из них включает в себя другой. Особенность этого отношения заключается в том, что компонент может существовать только как часть контейнера. В UML композиция обозначается линией со стрелкой на одном конце и заполненным ромбом на другом конце. Ромб направлен в сторону контейнера, а стрелка — в сторону включаемого объекта.

Агрегация в UML-диаграммах. Кафедра содержит профессоров.

Агрегация — это менее строгий вариант композиции, когда один объект просто имеет ссылку на другой объект. Здесь контейнер не управляет жизненным циклом компонента. Компонент может существовать отдельно от контейнера. В UML агрегация изображается как композиция, но с пустым ромбом.

ОСНОВЫ ПАТТЕРНОВ

Что такое паттерн?

Паттерн проектирования — это часто встречаемое решение определённой проблемы при проектировании архитектуры программ.

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

Паттерны часто путают с алгоритмами, ведь оба понятия описывают типовые решения каких-то известных проблем. И если алгоритм — это чёткий набор действий, то паттерн — это высокоуровневое описание решения, реализация которого может отличаться в двух разных программах.

Если привести аналогии, то алгоритм — это кулинарный рецепт с чёткими шагами, а паттерн — инженерный чертёж, на котором нарисовано решение, но не конкретные шаги его получения.

Из чего состоит паттерн?

Описания паттернов обычно очень формальны и чаще всего состоят из таких пунктов:

проблемы, которую решает паттерн;

мотивации к решению проблемы способом, который предлагает паттерн;

структуры классов, составляющих решение;

примера на одном из языков программирования;

особенностей реализации в различных контекстах;

связей с другими паттернами.

Такой формализм в описании позволяет собрать обширный каталог паттернов, проверяя все новые паттерны на состоятельность.

Классификация паттернов

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

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

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

Кроме этого, паттерны отличаются и предназначением. В этой книге будут рассмотрены три основные группы паттернов:

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

Структурные паттерны показывают различные способы построения связей между объектами.

Поведенческие паттерны заботятся об эффективной коммуникации между объектами.

Кто придумал паттерны?

По определению, паттерны не придумывают, а скорее «открывают». Это не какие-то супер-оригинальные решения, а наоборот — часто встречающиеся, типовые решения одной и той же проблемы.

Концепцию паттернов впервые описал Кристофер Александер 1A Pattern Language: Towns, Buildings, Construction (-language-book). в книге «Язык шаблонов. Города. Здания. Строительство». В книге описан «язык» для проектирования окружающей среды, единицы которого — шаблоны (или паттерны, что ближе к оригинальному термину patterns) — отвечают на архитектурные вопросы: какой высоты сделать окна, сколько этажей должно быть в здании, какую площадь в микрорайоне отвести под деревья и газоны.

Идея показалась заманчивой четвёрке авторов: Эриху Гамме, Ричарду Хелму, Ральфу Джонсону, Джону Влиссидесу. В 1995 году они написали книгу «Design Patterns: Elements of Reusable Object-Oriented Software» 2Design Patterns: Elements of Reusable Object-Oriented Software (-book)., в которую вошли 23 паттерна, решающие различные проблемы объектно-ориентированного дизайна. Название книги было слишком длинным, чтобы кто-то смог всерьёз его запомнить. Поэтому вскоре все стали назвать её «book by the gang of four», то есть «книга от банды четырёх», а затем и вовсе «GOF book».

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

Зачем знать паттерны?

Вы можете вполне успешно работать, не зная ни одного паттерна. Более того, вы могли уже не раз реализовать какой-то из паттернов, даже не подозревая об этом.

Но осознанное владение инструментом как раз и отличает профессионала от любителя. Вы можете забить гвоздь молотком, а можете и дрелью, если сильно постараетесь. Но профессионал знает, что главная фишка дрели совсем не в этом. Итак, зачем же знать паттерны?

Проверенные решения. Вы тратите меньше времени, используя готовые решения, вместо повторного изобретения велосипеда. До некоторых решений вы смогли бы додуматься и сами, но многие могут быть для вас открытием.

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

Общий программистский словарь. Вы произносите название паттерна, вместо того, чтобы час объяснять другим программистам какой крутой дизайн вы придумали и какие классы для этого нужны.

ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ

Качества хорошей архитектуры

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

Повторное использование кода

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

Повторное использование программной архитектуры и кода — это один из самых распространённых способов снижения стоимости разработки. Логика проста: вместо того, чтобы разрабатывать что-то по втором уразу, почему бы не использовать прошлые наработки в новом проекте?

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

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

Приведу цитату Эрика Гаммы, одного из первооткрывателей паттернов, о повторном использовании кода и роли паттернов в нём.

Существует три уровня повторного использования кода. На самом нижнем уровне находятся классы: полезные библиотеки классов, контейнеры, а также «команды» классов вроде контейнеров/итераторов.

Фреймворки стоят на самом верхнем уровне. В них важна только архитектура. Они определяют ключевые абстракции для решения некоторых бизнес-задач, представленных в виде классов и отношений между ними. Возьмите JUnit, это маленький фреймворк, даже базовый, я бы сказал. В нём есть всего несколько классов — Test, TestCase и TestSuite, а также связи между ними. Обычно, фреймворк имеет гораздо больший охват, чем один класс. Вы должны вклиниться в фреймворк, расширив какой-то из его классов. Всё работает по так называемому голливудскому принципу "не звоните нам, мы сами вам перезвоним". Фреймворк позволяет вам задать какое-то своё поведение, а затем сам вызывает его, когда приходит черёд что-то делать. То же происходит и в JUnit. Он обращается к вашему классу, когда нужно выполнить тест, но всё остальное происходит внутри фреймворка.

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

Что ещё замечательно в этом среднем уровне так это то, что паттерны — это менее рискованный способ повторного использования, чем фреймворки. Разработка фреймворка — это крайне рисковая и дорогая инвестиция. В то же время, паттерны позволяют вам повторно использовать идеи и концепции в отрыве от конкретного кода.

Расширяемость

Изменения часто называют главным врагом программиста.

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

Вы выпустили видео игру под Windows, но затем понадобилась поддержка macOS.

Вы сделали интерфейсный фреймворк с квадратными кнопками, но клиенты начали просить круглые.

У каждого программиста есть дюжина таких историй. Есть несколько причин, почему так происходит.

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

Во-вторых, изменения могут прийти извне. У вас есть идеальный клиент, который с первого раза сформулировал то, что ему надо, а вы в точности это сделали. Прекрасно! Но вот, выходит новая версия операционной системы, в которой ваша программа перестаёт работать. Чертыхаясь, вы лезете в код, чтобы внести кое-какие изменения.

Можно посмотреть на это с оптимистичной стороны: если кто-то просит вас что-то изменить в программе, значит она всё ещё кому-то нужна.

Вот почему даже мало-мальски опытный программист проектирует архитектуру и пишет код с учётом будущих изменений.

Базовые принципы проектирования

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

Всё это правильные вопросы, но для каждой программы ответ будет чуточку отличаться. Давайте рассмотрим универсальные принципы проектирования, которые помогут вам формулировать ответы на эти вопросы самостоятельно.

Кстати, большинство паттернов, приведённых в этой книге, основанны именно на перечисленных ниже принципах.

Инкапсулируйте то, что меняется

Определите аспекты программы, класса или метода, которые меняются чаще всего и отделите их того, что остаётся постоянным.

Этот принцип преследует единственную цель — уменьшить последствия, вызываемые изменениями.

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

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

Изолируя изменчивые части программы в отдельных модулях, классах или методах, вы уменьшаете количество кода, который затронут последующие изменения. Следовательно, вам нужно будет потратить меньше усилий на то, чтобы привести программу в рабочее состояние, отладить и протестировать изменившийся код. Где меньше работы, там меньше стоимость разработки. А где меньше стоимость, там и преимущество перед конкурентами.

Пример инкапсуляции на уровне метода

Представьте, что вы разрабатываете интернет-магазин. Где-то внутри вашего кода может существовать метод getOrderTotal, который рассчитывает финальную сумму заказа, учитывая размер налога.

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

Из-за этих изменений вам постоянно придётся трогать метод getOrderTotal, который, по правде, не особо интересуется деталями вычисления налогов.

method getOrderTotal(order) is   total = 0   foreach item in order.lineItems     total += item.price * item.quantity   if (order.country == "US")     total -= total * 0.07 // US sales tax   else if (order.country == "EU"):     total -= total * 0.20 // European VAT       return total

ДО: правила вычисления налогов смешаны с основным кодом метода.

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

method getOrderTotal(order) is   total = 0   foreach item in order.lineItems     total += item.price * item.quantity      total -= total * getTaxAmount(order.country)   return total method getTaxAmount(country) is   if (country == "US")     return 0.07 // US sales tax   else if (country == "EU"):     return 0.20 // European VAT   else     return 0

ПОСЛЕ: размер налога можно получить, вызвав один метод.

Теперь изменения налогов будут изолированы в рамках одного метода. Более того, если логика вычисления налогов станет ещё более сложной, вам будет легче извлечь этот метод в собственный класс.

Пример инкапсуляции на уровне класса

Извлечь логику налогов в собственный класс? Если логика налогов стала слишком сложной, то почему бы и нет?

ДО: вычисление налогов в классе заказов.

Объекты заказов станут делегировать вычисление налогов отдельному объекту-калькулятору налогов.

ПОСЛЕ: вычисление налогов скрыто в классе заказов.

Программируйте на уровне интерфейса

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

Гибкость архитектуры выражает в том, чтобы её можно было расширять, не ломая существующий код. Для примера вернёмся к классу котов. Класс Кот, который ест только сардельки, будет менее гибким, чем тот, что может есть любую еду. Но при этом, последнего можно будет кормить и сардельками, ведь они являются едой.

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

Определите, что именно нужно одному объекту от другого, какие методы он вызывает.

Затем, опишите эти методы в отдельном интерфейсе.

Сделайте так, чтобы класс-зависимость следовал этому интерфейс. Скорей всего, нужно будет только добавить этот интерфейс в описание класса.

Теперь вы можете и сделать второй класс зависимым от интерфейса, а не конкретного класса.

До и после извлечения интерфейса. Код справа более гибкий, чем тот, что слева, но и более сложный.

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

Пример

Давайте рассмотрим ещё один пример, где работа на уровне интерфейса оказывается выигрышней привязки к конкретным классам. Представьте, что вы делаете симулятор софтверной компании. У вас есть различные классы работников, которые делают ту или иную работу внутри компании.

ДО: классы жёстко связаны.

Вначале класс компании жёстко привязан к конкретным классам работников. Несмотря на то, что каждый тип работников делает разную работу, мы можем свести их методы работы к одному виду, выделив для всех классов общий интерфейс.

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

ЛУЧШЕ: полиморфизм помог упросить код, но основной код компании всё ещё зависит от конкретных классов сотрудников.

Тем не менее, класс компании всё ещё остаётся жёстко привязанным к конкретным классам работников. Это не очень хорошо, особенно, если предположить, что нам понадобится реализовать несколько видов компаний. Все эти компании будут отличаться тем, какие конкретно работники в них нужны.

Мы можем сделать метод получения сотрудников в базовом классе компании абстрактным. Конкретные компании должны будут сами позаботиться о создании объектов сотрудников. А значит — каждый тип компаний сможет иметь собственный набор сотрудников.

ПОСЛЕ: основной код класса компании стал независимым от классов сотрудников. Конкретных сотрудников создают конкретные классы компаний.

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

Кстати, вы только что увидели пример одного из паттернов, а именно — Фабричного метода. Мы ещё вернёмся к нему в дальнейшем.

Предпочитайте композицию наследованию

Наследование — это самый простой и быстрый способ повторного использования кода между классами. У вас есть два класса с дублирующимся кодом. Создайте для них общий базовый класс и перенесите в него общее поведение. Что может быть проще?

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

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

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

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

Подклассы слишком тесно связаны с родительским классом. Любое изменение в родителе может сломать поведение в подклассах.

Повторное использование кода через наследование может привести к разрастанию иерархии классов.

У наследования есть альтернатива, называемая композицией. Если наследование можно выразить словом «является» (автомобиль является транспортом), то композицию — словом «содержит» (автомобиль содержит двигатель).

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

Пример

Предположим, вам нужно смоделировать модельный ряд автопроизводителя. У вас есть легковые автомобили и грузовики. Причём, они бывают с электрическим двигателем, и с двигателем на бензине. К тому же, они отличаются режимами навигации — есть модели с ручным управлением и автопилотом.

НАСЛЕДОВАНИЕ: развитие классов в нескольких плоскостях (тип груза × тип двигателя × тип навигации) приводит к комбинаторному взрыву.

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

Решить проблему можно с помощью композиции. Вместо того, чтобы объекты сами реализовывали то или иное поведение, они могут делегировать его другим объектам.

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

КОМПОЗИЦИЯ: различные виды функциональности выделены в собственные иерархии классов.

Такая структура свойственна паттерну Стратегия, о котором мы тоже поговорим в этой книге.

Принципы SOLID

Рассмотрим ещё пять принципов проектирования, которые известны как SOLID. Эти принципы были впервые изложены Робертом Мартином в книге Agile Software Development, Principles, Patterns, and Practices 3Agile Software Development, Principles, Patterns, and Practices (-book)..

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

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

Но, как и всё в этой жизни, соблюдение этих принципов имеет свою цену. Здесь это в основном выражается в усложнении кода программы. В реальной жизни, пожалуй, нет такого кода, в котором бы соблюдались все эти принципы сразу. Поэтому помните о балансе и не воспринимайте всё изложенное как догму.

S Принцип единой ответственности

ingle Responsibility Principle

У класса должна быть только один мотив для изменения.

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

Принцип единственной ответственности предназначен для борьбы со сложностью. Когда в вашем приложении всего 200 строк, то дизайн как таковой вообще не нужен. Достаточно аккуратно написать 5-7 методов и всё будет хорошо. Проблемы возникают, когда система растёт и увеличивается в масштабах. Когда класс разрастается, он просто перестаёт помещаться в голове. Навигация затрудняется, на глаза попадаются ненужные детали, связанные с другим аспектом, в результате, количество понятий начинают превышать мозговой стек, и вы начинаете терять контроль над кодом.

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

Хорошо иметь возможность сосредоточиться на сложных аспектах системы по отдельности. Но если вам становится сложно это делать, применяйте принцип единственной ответственности, разделяя ваши классы на части.

Пример

Класс Employee имеет сразу несколько причин для изменения. Первая связана с основной задачей класса — это управлением данными сотрудника. Но есть и вторая: изменения, связанные с форматированием отчёта для печати, будут затрагивать класс сотрудников.

ДО: класс сотрудника содержит разнородные поведения.

Проблему можно решить, выделив операцию печати в отдельный класс.

ПОСЛЕ: лишнее поведение переехало в собственный класс.

O Принцип открытости/закрытости

pen/closed Principle

Расширяйте классы, но не изменяйте их первоначальный код.

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

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

В то же время, класс можно назвать закрытым (а лучше сказать законченным), если он готов для использования другими классами. Это означает, что интерфейс класса уже окончательно определён и не будет изменяться в будущем.

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

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

Пример

Класс заказов имеет метод расчёта стоимости доставки, причём способы доставки «зашиты» непосредственно в сам метод. Если вам нужно будет добавить новый способ доставки, то придётся трогать весь класс Order.

ДО: код класса заказа нужно будет изменять при добавлении нового способа доставки.

Проблему можно решить, если применить паттерн Стратегия. Для этого нужно выделить способы доставки в собственные классы с общим интерфейсом.

ПОСЛЕ: новые способы доставки можно добавить, не трогая класс заказов.

Теперь при добавлении нового способа доставки нужно будет реализовать новый класс интерфейса доставки, не трогая класса заказов. Объект способа доставки в класс заказа будет подавать клиентский код, который раньше устанавливал способ доставки простой строкой.

Бонус этого решения в том, что расчёт времени и даты доставки тоже можно поместить в новые классы, повинуясь принципу единственной ответственности.

L Принцип подстановки Лисков 4Принцип назван в честь Барбары Лисков, которая впервые сформулировала его 1987 году в работе Data abstraction and hierarchy:

iskov Substitution Principle

Подклассы должны дополнять, а не замещать поведение базового класса.

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

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

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

Типы параметров метода подкласса должны совпадать или быть боле абстрактными, чем типы параметров базового метода. Довольно запутанно? Рассмотрим, как это работает на примере.

Базовый класс содержит метод feed(Cat c), который умеет кормить домашних котов. Клиентский код это знает и всегда передаёт в метод кота.

Хорошо: Вы создали подкласс, и переопределили метод кормёжки так, чтобы накормить любое животное: feed(Animal c). Если подставить этот подкласс в клиентский код, то ничего страшного не произойдёт. Клиентский код подаст в метод кота, но метод умеет кормить всех животных, поэтому накормит и кота.

Плохо: Вы создали другой подкласс, в котором метод умеет кормить только бенгальскую породу котов (подкласс котов): feed(BengalCat t). Что будет с клиентским кодом? Он всё так же подаст в метод обычного кота. Но метод умеет кормить только бенгалов, поэтому не сможет отработать, сломав клиентский код.

Тип возвращаемого значения метода подкласса должен совпадать или быть подтипом возвращаемого значения базового метода. Здесь всё то же, что и в предыдущем пункте, но наоборот.

Базовый метод: buyCat(): Cat. Клиентский код ожидает на выходе любого домашнего кота.

Хорошо: Метод подкласса: buyCat(): BengalCat. Клиентский код получит бенгальского кота, который является домашним котом, поэтому всё будет хорошо.

Плохо: Метод подкласса: buyCat(): Animal. Клиентский код сломается, так как это непонятное животное (возможно, крокодил) не поместится в ящике-переноске для кота.

Ещё один анти-пример, из мира языков с динамической типизацией: базовый метод возвращает строку, а переопределённый метод — число.

Метод не должен выбрасывать исключения, которые не свойственны базовому методу. Типы исключений в переопределённом методе должны совпадать или быть подтипами исключений, которые выбрасывает базовый метод. Блоки try-catch в клиентском коде нацелены на конкретные типы исключений, выбрасываемые базовым методом. Поэтому неожиданное исключение, выброшенное подклассом, может проскочить сквозь обработчики клиентского кода и обрушить программу.

В большинстве современных языков программирования, особенно строго типизированных (Java, C# и другие), перечисленные ограничения встроены прямо в компилятор. Поэтому вы попросту не сможете собрать программу, нарушив их.

Метод не должен ужесточать _пред_условия. Например, базовый метод работает с параметром типа int. Если подкласс требует, чтобы значение этого параметра к тому же было больше нуля, то это ужесточает предусловия. Клиентский код, который до этого отлично работал, подавая в метод негативные числа, теперь сломается при работе с объектом подкласса.

Метод не должен ослаблять _пост_условия. Например, базовый метод требует, чтобы по завершению метода все подключения к базе данных были бы закрыты, а подкласс оставляет эти подключения открытыми, чтобы потом повторно использовать. Но клиентский код базового класса ничего об этом не знает. Он может завершить программу сразу после вызова метода, оставив запущенные процессы-призраки в системе.

Инварианты класса должны остаться без изменений. Инвариант — это набор условий, при которых объект имеет смысл. Например, инвариант кота — это наличие четырёх лап, хвоста, способность мурчать и прочее. Инвариант может быть описан не только явным контрактом или проверками в методах класса, но и косвенно, например, юнит-тестами или клиентским кодом.

Этот пункт проще всего нарушить при наследовании, так как вы можете попросту не подозревать о каком-то из условий инварианта сложного класса. Идеальным в этом отношении был бы подкласс, который только вводит новые методы и поля, не прикасаясь к полям базового класса.

Подкласс не должен изменять значения приватных полей базового класса. Этот пункт звучит странно, но в некоторых языках доступ к приватным полям можно получить через механизм рефлексии. В некоторых других языках (Python, JavaScript) и вовсе нет жёсткой защиты приватных полей.

Пример

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

ДО: подкласс «обнуляет» работу базового метода.

Метод сохранения в подклассе ReadOnlyDocuments выбросит исключение, если кто-то попытается вызвать его метод сохранения. Базовый метод не имеет такого ограничения. Из-за этого, клиентский код вынужден проверять тип документа при сохранении всех документов.

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

ПОСЛЕ: подкласс расширяет базовый класс новым поведением.

Проблему можно решить, если перепроектировав иерархию классов. Базовый класс сможет только открывать документы, но не сохранять их. Подкласс, который теперь будет называться WritableDocument, расширит поведение родителя, позволив сохранять документ.

I Принцип разделения интерфейса

nterface Segregation Principle

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

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

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

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

Пример

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

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

ДО: не все клиенты могут реализовать операции интерфейса.

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

ПОСЛЕ: раздутый интерфейс разбит на части.

D Принцип инверсии зависимостей

ependency Inversion Principle

Классы верхних уровней не должны зависеть от классов нижних уровней. Оба должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

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

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

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

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

Принцип инверсии зависимостей предлагает изменить направление, в котором происходит проектирование.

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

Это позволит вам убрать зависимость класса бизнес-логики от конкретного низкоуровневого класса, заменив её «мягкой» зависимостью от интерфейса.

Низкоуровневый класс, в свою очередь, станет зависимый от интерфейса, определённого бизнес-логикой.

Принцип инверсии зависимостей часто идёт в ногу с принципом открытости/закрытости: вы сможете расширять низкоуровневые классы и использовать их вместе с классами бизнес-логики, не изменяя код последних.

Пример

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

ДО: высокоуровневый класс зависит от низкоуровневого.

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

ПОСЛЕ: низкоуровневые классы зависят от высокоуровневой абстракции.

Таким образом, меняется направление зависимости. Если раньше высокий уровень зависел от низкого, то сейчас всё наоборот — низкоуровневые классы зависят от высокоуровневого интерфейса.

КАТАЛОГ ПАТТЕРНОВ

Порождающие паттерны

Эти паттерны отвечают за удобное и безопасное создание новых объектов или даже целых семейств объектов.

Фабричный Метод Factory Method Определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов. Абстрактная Фабрика Abstract Factory Позволяет создавать семейства связанных объектов, не привязываясь к конкретным классам создаваемых объектов. Строитель Builder Позволяет создавать сложные объекты пошагово. Строитель даёт возможность использовать один и тот же код строительства для получения разных представлений объектов. Прототип Prototype Позволяет копировать объекты, не вдаваясь в подробности их реализации. Одиночка Singleton Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа.

Фабричный метод

Также известен как: Виртуальный конструктор, Factory Method

Суть паттерна

Фабричный метод — это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов.

Проблема

Представьте, что вы создаёте программу управления грузовыми перевозками. Сперва вы рассчитываете перевозить товары только на автомобилях. Поэтому весь ваш код работает с объектами класса Грузовик.

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

Добавить новый класс не так то просто, если весь код уже завязан на конкретные классы.

Отличные новости, правда?! Но как насчёт кода? Большая часть существующего кода жёстко привязана к классам Грузовиков. Чтобы добавить в программу классы морских Судов понадобится перелопатить всю программу. Более того, если вы потом решите добавить ещё один вид транспорта, то всю эту работы придётся повторить.

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

Решение

Паттерн Фабричный метод предлагает создавать объекты не напрямую, используя оператор new, а через вызов особого фабричного метода. Не пугайтесь, объекты всё равно будут создаваться при помощи new, но делать это будет фабричный метод.

Подклассы могут изменять класс создаваемых объектов.

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

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

Все объекты-продукты должны иметь общий интерфейс.

Например, классы Грузовик и Судно реализуют интерфейс Транспорт с методом доставить. Каждый из этих классов реализует метод по-своему: грузовики везут грузы по земле, а судна — по морю. Фабричный метод в классе ДорожнойЛогистики вернёт грузовик, а класс МорскойЛогистики — судно.

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

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

Структура

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

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

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

Зачастую фабричный метод объявляют абстрактным, чтобы заставить все подклассы реализовать фабричный метод по-своему. Однако он может возвращать и какой-то продукт по умолчанию.

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

Конкретные создатели по-своему реализуют фабричный метод, производя те или иные конкретные продукты.

Фабричный метод не обязан всё время создавать новые объекты. Его можно переписать так, чтобы возвращать существующие объекты из какого-то хранилища или кэша.

Псевдокод

В этом примере Фабричный метод помогает создавать кросс-платформенные элементы интерфейса, не привязывая основной код к конкретным классам элементов.

Пример кросс-платформенного диалога.

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

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

Такой подход можно применить и для создания других элементов интерфейса. Хотя каждый новый тип элементов будет приближать вас к Абстрактной фабрике.

// Паттерн Фабричный Метод применим тогда, когда есть // иерархия классов продуктов. interface Button is   method render()   method onClick(f) class WindowsButton implements Button is   method render(a, b) is     // Отрисовать кнопку в стиле Windows.   method onClick(f) is     // Навесить на кнопку нативный обработчик события. class HTMLButton implements Button is   method render(a, b) is     // Вернуть HTML-код кнопки.   method onClick(f) is     // Навесить на кнопку обработчик события браузера. // Базовый класс фабрики. Заметьте, что "фабрика" – это // всего лишь дополнительная роль для класса. Он уже имеет // какую-то бизнес-логику, в которой требуется создание // разнообразных продуктов. class Dialog is   method renderWindow() is     // Отрисовать остальные элементы интерфейса.     Button okButton = createButton()     okButton.onClick(closeDialog)     okButton.render()   // Мы выносим весь код создания продуктов в особый   // Фабричный метод.   abstract method createButton() // Конкретные фабрики переопределяют фабричный метод и // возвращают из него собственные продукты. class WindowsDialog extends Dialog is   method createButton() is     return new WindowsButton() class WebDialog extends Dialog is   method createButton() is     return new HTMLButton() class ClientApplication is   field dialog: Dialog   // Приложение создаёт определённую фабрику в зависимости   // от конфигурации или окружения.   method initialize() is     config = readApplicationConfigFile()     if (config.OS == "Windows") then       dialog = new WindowsDialog()     else if (config.OS == "Web") then       dialog = new WebDialog()     else       throw new Exception("Error! Unknown operating system.")   // Весь остальной клиентский код работает с фабрикой и   // продуктами только через общий интерфейс, поэтому для   // него неважно какая фабрика была создана.   method main() is     dialog.initialize()     dialog.render()

Применимость

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

Фабричный метод отделяет код производства продуктов от остального кода, который эти продукты использует.

Благодаря этому, код производства можно расширять, не трогая основной код. Так, чтобы добавить поддержку нового продукта, вам нужно создать новый подкласс и определить в нём фабричный метод, возвращая оттуда экземпляр нового продукта.

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

Пользователи могут расширять классы вашего фреймворка через наследование. Но как сделать так, чтобы фреймворк создавал объекты из этих новых классов, а не из стандартных?

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

Например, вы используете готовый UI-фреймворк для своего приложения. Но вот беда, требуется иметь круглые кнопки, вместо стандартных прямоугольных. Вы создаёте класс RoundButton. Но как сказать главному классу фреймворка (UIFramework), чтобы он теперь создавал круглые кнопки, вместо стандартных.

Для этого вы создаёте подкласс UIWithRoundButtons из базового класса фреймворка, переопределяете в нём метод создания кнопки (createButton) и вписываете туда создание своего класса кнопок. Затем, используете UIWithRoundButtons вместо стандартного UIFramework.

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

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

Представьте, сколько действий вам нужно совершить, чтобы повторно использовать существующие объекты:

Сперва вам следует создать общее хранилище, чтобы хранить вы нём все создаваемые объекты.

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

А затем вернуть его клиентскому коду.

Но если свободных объектов нет — создать новый, не забыв добавить его в хранилище.

Весь этот код нужно куда-то поместить, чтобы не засорять клиентский код.

Самым удобным местом был бы конструктор объекта, ведь все эти проверки нужны только при создании объектов. Но, увы, конструктор всегда создаёт новые объекты, он не может вернуть существующий экземпляр.

Значит, должен другой метод, который бы отдавал как существующие, так и новые объекты. Им и станет фабричный метод.

Шаги реализации

Приведите все создаваемые продукты к общему интерфейсу.

В классе, который производит продукты, создайте пустой фабричный метод. В качестве возвращаемого типа укажите общий интерфейс продукта.

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

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

На этом этапе фабричный метод, скорее всего, будет выглядеть удручающе. В нём будет жить большой условный оператор, выбирающий класс создаваемого продукта. Но не волнуйтесь, мы вот-вот исправим это.

Для каждого типа продуктов заведите подкласс и переопределите в нём фабричный метод. Переместите туда код создания соответствующего продукта из суперкласса.

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

Например, у вас есть класс Почта с подклассами АвиаПочта и НаземнаяПочта, а также классы продуктов Самолёт, Грузовик и Поезд. Авиа соответствует Самолётам, но для НаземнойПочты есть сразу два продукта. Вы могли бы создать новый подкласс почты для поездов, но проблему можно решить и по-другому. Клиентский код может передавать в фабричный метод НаземнойПочты аргумент, контролирующий какой из продуктов будет создан.

Если после всех перемещений фабричный метод стал пустым, можете сделать его абстрактным. Если в нём что-то осталось — не беда, это будет его реализацией по умолчанию.

Преимущества и недостатки

Избавляет класс от привязки к конкретным классам продуктов.

Выделяет код производства продуктов в одно место, упрощая поддержку кода.

Упрощает добавление новых продуктов в программу.

Реализует принцип открытости/закрытости.

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

Отношения с другими паттернами

Многие архитектуры начинаются с применения Фабричного метода (более простого и расширяемого через подклассы) и эволюционируют в сторону Абстрактной фабрики, Прототипа или Строителя (более гибких, но и более сложных).

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

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

Прототип не опирается на наследование, но ему нужна сложная операция инициализации. Фабричный метод наоборот, построен на наследовании, но не требует сложной инициализации.

Фабричный метод можно рассматривать как частный случай Шаблонного метода. Кроме того, Фабричный метод нередко бывает частью большого класса с Шаблонными методами.

Дополнительные материалы

Если вы уже слышали о Фабрике, Фабричном методе и Абстрактной фабрике, но с трудом их различаете — почитайте нашу статью Сравнение фабрик.

Абстрактная фабрика

Также известен как: Abstract Factory

Суть паттерна

Абстрактная фабрика — это порождающий паттерн проектирования, который позволяет создавать семейства связанных объектов, не привязываясь к конкретным классам создаваемых объектов.

Проблема

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

Семейство зависимых продуктов. Скажем, Кресло + Диван + Столик.

Несколько вариаций этого семейства. Например, продукты Кресло, Диван и Столик представлены в трёх разных стилях: Ар-деко, Викторианском и Модерне.

Семейства продуктов и их вариации.

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

Клиенты расстраиваются, если получают несочетающиеся продукты.

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

Решение

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

Все вариации одного и того же объекта должны жить в одной иерархии классов.

Далее, вы создаёте «абстрактную фабрику» — общий интерфейс, который содержит методы создания всех продуктов семейства (например, создатьКресло, создатьДиван и создатьСтолик). Эти операции должны возвращать абстрактные типы продуктов, представленные интерфейсами, которые мы выделили ранее — Кресла, Диваны и Столики.

Конкретные фабрики соответствуют определённой вариации семейства продуктов.

Как насчёт вариаций продуктов? Для каждой вариации семейства продуктов мы должны создать свою собственную фабрику, реализовав абстрактный интерфейс. Фабрики создают продукты одной вариации. Например, ФабрикаМодерн будет возвращать только КреслаМодерн,ДиваныМодерн и СтоликиМодерн.

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

Клиентскому коду должно быть всё равно с какой фабрикой работать.

Например, клиентский код просит фабрику сделать стул. Он не знает какого типа фабрика это была. Он не знает, получит викторианский или модерновый стул. Для него важно, чтобы на этом стуле можно сидеть, и чтобы этот стул отлично смотрелся с диваном той же фабрики.

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

Структура

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

Конкретные продукты — большой набор классов, которые относятся к различным абстрактным продуктам (кресло/столик), но имеют одни и те же вариации (Викториан./Модерн).

Абстрактная фабрика объявляет методы создания различных абстрактных продуктов (кресло/столик).

Конкретные фабрики относятся каждая к своей вариации продуктов (Викториан./Модерн) и реализуют методы абстрактной фабрики, позволяя создавать все продукты определённой вариации.

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

Псевдокод

В этом примере Абстрактная фабрика создаёт кросс-платформенные элементы интерфейса и следит за тем, чтобы они соответствовали выбранной операционной системе.

Пример кросс-платформенного графического интерфейса пользователя.

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

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

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

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

Чтобы добавить в программу новую вариацию элементов (например, для поддержки Linux), вам не нужно трогать клиентский код. Достаточно создать ещё одну фабрику, производящую эти элементы.

// Этот паттерн предполагает, что у вас есть несколько // семейств продуктов, находящихся в отдельных иерархиях // классов (Button/Checkbox). Продукты одного семейства // должны иметь общий интерфейс. interface Button is   method paint() // Все семейства продуктов имеют одинаковые // вариации (macOS/Windows). class WinButton implements Button is   method paint() is     // Отрисовать кнопку в стиле Windows. class MacButton implements Button is   method paint() is     // Отрисовать кнопку в стиле macOS. interface Checkbox is   method paint() class WinCheckbox implements Checkbox is   method paint() is     // Отрисовать чекбокс в стиле Windows. class MacCheckbox implements Checkbox is   method paint() is     // Отрисовать чекбокс в стиле macOS. // Абстрактная фабрика знает обо всех (абстрактных) // типах продуктов. interface GUIFactory is   method createButton():Button   method createCheckbox():Checkbox // Каждая конкретная фабрика знает и создаёт только продукты // своей вариации. class WinFactory implements GUIFactory is   method createButton():Button is     return new WinButton()   method createCheckbox():Checkbox is     return new WinCheckbox() // Несмотря на то что фабрики оперируют конкретными // классами, их методы возвращают абстрактные типы // продуктов. Благодаря этому, фабрики можно взаимозаменять, // не изменяя клиентский код. class MacFactory implements GUIFactory is   method createButton():Button is     return new MacButton()   method createCheckbox():Checkbox is     return new MacCheckbox() // Код, использующий фабрику, не волнует с какой конкретно // фабрикой он работает. Все получатели продуктов работают с // продуктами через абстрактный интерфейс. class Application is   private field button: Button   constructor Application(factory: GUIFactory) is     this.factory = factory   method createUI()     this.button = factory.createButton()   method paint()     button.paint() // Приложение выбирает тип и создаёт конкретные фабрики // динамически исходя из конфигурации или окружения. class ApplicationConfigurator is   method main() is     config = readApplicationConfigFile()     if (config.OS == "Windows") then       factory = new WinFactory()     else if (config.OS == "Web") then       factory = new MacFactory()     else       throw new Exception("Error! Unknown operating system.")     Application app = new Application(factory)

Применимость

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

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

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

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

Шаги реализации

Создайте таблицу соотношений типов продуктов к вариациям семейств продуктов.

Сведите все вариации продуктов к общим интерфейсам.

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

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

Измените код инициализации программы так, чтобы она создавала определённую фабрику и передавала её в клиентский код.

Замените в клиентском коде участки создания продуктов через конструктор вызовами соответствующих методов фабрики.

Преимущества и недостатки

Гарантирует сочетаемость создаваемых продуктов.

Избавляет клиентский код от привязки к конкретным классам продуктов.

Выделяет код производства продуктов в одно место, упрощая поддержку кода.

Упрощает добавление новых продуктов в программу.

Реализует принцип открытости/закрытости.

Усложняет код программы за счёт множества дополнительных классов.

Требует наличия всех типов продуктов в каждой вариации.

Отношения с другими паттернами

Многие архитектуры начинаются с применения Фабричного метода (более простого и расширяемого через подклассы) и эволюционируют в сторону Абстрактной фабрики, Прототипа или Строителя (более гибких, но и более сложных).

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

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

Абстрактная фабрика может быть использована вместо Фасада для того, чтобы скрыть платформо-зависимые классы.

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

Абстрактная фабрика, Строитель и Прототип могут быть реализованы при помощи Одиночки.

Дополнительные материалы

Если вы уже слышали о Фабрике, Фабричном методе и Абстрактной фабрике, но с трудом их различаете — почитайте нашу статью Сравнение фабрик.

Строитель

Также известен как: Builder

Суть паттерна

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

Проблема

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

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

Например, давайте подумаем о том, как создать объект Дом. Чтобы построить стандартный дом, нужно поставить 4 стены, установить двери, вставить пару окон и постелить крышу. Но что, если вы хотите дом побольше, посветлее, с бассейном, садом и прочим добром?

Самое простое решение — расширить класс Дом, создав подклассы для всех комбинаций параметров дома. Проблема такого подхода — это громадное количество классов, которые вам придётся создать. Каждый новый параметр, вроде цвета обоев или материала кровли, заставит вас создавать всё больше и больше классов для перечисления всех возможных вариантов.

Чтобы не плодить подклассы, вы можете подойти к решению с другой стороны. Вы можете создать гигантский конструктор Дома, принимающий уйму параметров для контроля над создаваемым продуктом. Действительно, это избавит вас от подклассов, но приведёт к другой проблеме.

Конструктор с множеством параметров имеет свой недостаток. Не все параметры нужны большую часть времени.

Большая часть этих параметров будет простаивать, а вызовы конструктора будут выглядеть монструозно из-за длинного списка параметров. К примеру, далеко не каждый дом имеет бассейн, поэтому параметры, связанные с бассейнами, будут простаивать бесполезно в 99% случаев.

Решение

Паттерн Строитель предлагает вынести конструирование объекта за пределы его собственного класса, поручив это дело отдельным объектам, называемым строителями.

Строитель позволяет создавать сложные объекты пошагово. Промежуточный результат защищён от стороннего вмешательства.

Паттерн предлагает разбить процесс конструирования объекта на отдельные шаги (например, построитьСтены, вставитьДвери и т.д.) Чтобы создать объект, вам нужно поочерёдно вызывать методы строителя. Причём не нужно запускать все шаги, а только те, что нужны для производства объекта определённой конфигурации.

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

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

Разные Строители выполнят одну и ту же задачу по-разному.

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

Директор

Вы можете пойти дальше и выделить вызовы методов строителя в отдельный класс, называемый «Директором». В этом случае директор будет задавать порядок шагов строительства, а строитель — выполнять их.

Директор знает, какие шаги должен выполнить объект-Строитель, чтобы произвести продукт.

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

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

Структура

Интерфейс строителя объявляет шаги конструирования продуктов, общие для всех видов строителей.

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

Продукт — создаваемый объект. Продукты, сделанные разными строителями, не обязаны иметь общий интерфейс.

Директор определяет порядок вызова строительных шагов для производства той или иной конфигурации объектов.

Обычно, Клиент подаёт в конструктор директора уже готовый объект-строитель, и в дальнейшем данный директор использует только его. Но возможен и другой вариант, когда клиент передаёт строителя через параметр строительного метода директора. В этом случае можно каждый раз применять разных строителей для производства различных представлений объектов.

Псевдокод

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

Пример пошагового конструирования автомобилей и инструкций к ним.

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

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

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

Очевидно, что бумажное руководство и железный автомобиль — это две разных вещи, не имеющих ничего общего. По этой причине, мы должны получать результат напрямую от строителей, а не от директора. Иначе, нам пришлось бы жёстко привязать директора к конкретным классам автомобилей и руководств.

// Строитель может создавать различные продукты, используя // один и тот же процесс строительства. class Car is   // Автомобили могут отличаться комплектацией: типом   // двигателя, количеством сидейний, могут иметь или не иметь   // GPS и систему навигации и т.д. Кроме того, автомобили   // могут быть городскими, спортивными или внедорожниками. class Manual is   // Руководство пользователя для данной конфигурации   // автомобиля. // Интерфейс строителя объявляет все возможные этапы и шаги // конфигурации продукта. interface Builder is   method reset()   method setSeats(...)   method setEngine(...)   method setTripComputer(...)   method setGPS(...) // Все конкретные строители реализуют общий // интерфейс по-своему. class CarBuilder implements Builder is   private field car:Car   method reset()     // Поместить новый объект Car в поле "car".   method setSeats(...) is     // Установить указанное количество сидений.   method setEngine(...) is     // Установить поданный двигатель.   method setTripComputer(...) is     // Установить поданную систему навигации.   method setGPS(...) is     // Установить или снять GPS.   method getResult(): Car is     // Вернуть текущий объект автомобиля. // В отличие от других создающих паттернов, строители могут // создавать совершенно разные продукты, не имеющие // общего интерфейса. class CarManualBuilder implements Builder is   private field manual:Manual   method reset()     // Поместить новый объект Manual в поле "manual".   method setSeats(...) is     // Описать сколько мест в машине.   method setEngine(...) is     // Добавить в руководство описание двигателя.   method setTripComputer(...) is     // Добавить в руководство описание системы навигации.   method setGPS(...) is     // Добавить в инструкцию инструкцию GPS.   method getResult(): Manual is     // Вернуть текущий объект руководства. // Директор знает в какой последовательности заставлять // работать строителя. Он работает с ним через общий // интерфейс строителя. Из-за этого, он может не знать какой // конкретно продукт сейчас строится. class Director is   method constructSportsCar(builder: Builder) is     builder.reset()     builder.setSeats(2)     builder.setEngine(new SportEngine())     builder.setTripComputer(true)     builder.setGPS(true) // Директор получает объект конкретного строителя от клиента // (приложения). Приложение само знает какой строитель // использовать, чтобы получить нужный продукт. class Application is   method makeCar is     director = new Director()     CarBuilder builder = new CarBuilder()     director.constructSportsCar(builder)     Car car = builder.getResult()     CarManualBuilder builder = new CarManualBuilder()     director.constructSportsCar(builder)     // Готовый продукт возвращает строитель, так как     // директор чаще всего не знает и не зависит от     // конкретных классов строителей и продуктов.     Manual manual = builder.getResult()

Применимость

Когда вы хотите избавиться от «телескопического конструктора».

Допустим, у вас есть один конструктор с десятью опциональными параметрами. Его неудобно вызывать, поэтому вы создали ещё десять конструкторов с меньшим количеством параметров. Всё что они делают — это переадресуют вызов к главному конструктору, подавая какие-то значения по умолчанию в качестве опциональных параметров.

class Pizza {   Pizza(int size) { ... }           Pizza(int size, boolean cheese) { ... }       Pizza(int size, boolean cheese, boolean pepperoni) { ... }       // ...

Такого монстра можно создать только в языках, имеющих механизм перегрузки методов, например С# или Java.

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

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

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

Интерфейс строителей определит все возможные этапы конструирования. Каждому представлению будет соответствовать собственный класс-строитель. А порядок этапов строительства будет задавать класс-директор.

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

Строитель конструирует объекты пошагово, а не за один проход. Более того, шаги строительства можно выполнять рекурсивно. А без этого не построить древовидную структуру вроде Компоновщика.

Заметьте, что Строитель не позволяет посторонним объектам иметь доступ к конструируемому объекту пока тот не будет полностью готов. Это предотвращает клиентский код от получения незаконченных «битых» объектов.

Шаги реализации

Убедитесь в том, что создание разных представлений объекта можно свести к общим шагам.

Опишите эти шаги в общем интерфейсе строителей.

Для каждого из представлений объекта-продукта создайте по одному классу-строителю и реализуйте их методы строительства.

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

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

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

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

Преимущества и недостатки

Позволяет создавать продукты пошагово.

Позволяет использовать один и тот же код для создания различных продуктов.

Изолирует сложный код сборки продукта от его основной бизнес-логики.

Усложняет код программы за счёт дополнительных классов.

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

Отношения с другими паттернами

Многие архитектуры начинаются с применения Фабричного метода (более простого и расширяемого через подклассы) и эволюционируют в сторону Абстрактной фабрики, Прототипа или Строителя (более гибких, но и более сложных).

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

Строитель позволяет пошагово сооружать дерево Компоновщика.

Паттерн Строитель может быть построен в виде Моста: директор будет играть роль абстракции, а строители — реализации.

Абстрактная фабрика, Строитель и Прототип могут быть реализованы при помощи Одиночки.

Прототип

Также известен как: Клон, Prototype

Суть паттерна

Прототип — это порождающий паттерн проектирования, который позволяет копировать объекты, не вдаваясь в подробности их реализации.

Проблема

У вас есть объект, который нужно скопировать. Как это сделать? Нужно создать пустой объект такого же класса, а затем поочерёдно скопировать значения всех полей из старого объекта в новый.

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

Копирование «извне» не всегда возможно в реальности.

Но есть и другая проблема. Копирующий код станет зависим от классов копируемых объектов. Ведь чтобы перебрать все поля объекта, нужно привязаться к его классу. Из-за этого вы не сможете копировать объекты, зная только их интерфейсы, но не конкретные классы.

Решение

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

Реализация этого метода в разных классах очень схожа. Метод создаёт новый объект текущего класса и копирует в него значения всех полей объекта. Так получится скопировать даже приватные поля, так как большинство языков программирования разрешает доступ к приватным полям отдельного объекта текущего класса.

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

Предварительно заготовленные прототипы могут стать заменой подклассам.

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

Аналогия из жизни

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

Пример деления клетки.

Прототип на производстве не делает копию самого себя, поэтому более близкий пример паттерна — деление клеток. После митозного деления клеток образуются две совершенно идентичные клетки. Оригинальная клетка отыгрывает роль прототипа, принимает активную роль в создании нового объекта.

Структура

Базовая реализация

Интерфейс прототипов описывает операции клонирования. В большинстве случаев — это единственный метод clone.

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

Клиент создаёт копию объекта, обращаясь к нему через общий интерфейс прототипов.

Реализация с общим хранилищем прототипов

Хранилище прототипов облегчает доступ к часто используемым прототипам, храня предсозданный набор эталонных, готовых к копированию объектов. Простейшее хранилище может быть построено с помощью хеш-таблицы вида имя-прототипа → прототип. Но для удобства поиска, прототипы можно маркировать и другими критериями, а не только условным именем.

Псевдокод

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

Пример клонирования иерархии геометрических фигур.

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

// Базовый прототип. abstract class Shape is   field X: int   field Y: int   field color: string   // Копирование всех полей объекта происходит   // в конструкторе.   constructor Shape(source: Shape) is     if (source != null) then       this.X = source.X       this.Y = source.Y       this.color = source.color   // Результатом операции клонирования всегда будет объект   // из иерархии классов Shape.   abstract method clone(): Shape // Конкретный прототип. Метод клонирования создаёт новый // объект и передаёт в его конструктор для копирования // собственный объект. Этим мы пытаемся получить атомарность // операции клонирования. В данной реализации, пока не // выполнится конструктор, нового объекта ещё не существует. // Но как только конструктор завершён, мы получаем полностью // готовый объект-клон, а не пустой объект, который нужно // ещё заполнить. class Rectangle extends Shape is   field width: int   field height: int   constructor Rectangle(source: Rectangle) is     // Вызов родительского конструктора нужен, чтобы     // скопировать потенциальные приватные поля,     // объявленные в родительском классе.     super(source)     if (source != null) then       this.width = source.width       this.height = source.height   method clone(): Shape is     return new Rectangle(this) class Circle extends Shape is   field radius: int   constructor Circle(source: Circle) is     super(source)     if (source != null) then       this.radius = source.radius   method clone(): Shape is     return new Circle(this) // Где-то в клиентском коде. class Application is   field shapes: array of Shape   constructor Application() is     Circle circle = new Circle()     circle.X = 10     circle.Y = 20     circle.radius = 15     shapes.add(circle)     Circle anotherCircle = circle.clone()     shapes.add(anotherCircle)     // anotherCircle будет содержать точную     // копию circle.     Rectangle rectangle = new Rectangle()     rectangle.width = 10     rectangle.height = 20     shapes.add(rectangle)   method businessLogic() is     // Неочевидный плюс Прототипа в том, что вы можете     // клонировать набор объектов, не зная их     // конкретных классов.     Array shapesCopy = new Array of Shapes.     // Например, мы не знаем какие конкретно объекты     // находятся внутри массива shapes, так как он     // объявлен с типом Shape. Но благодаря     // полиморфизму, мы можем клонировать все объекты     // «вслепую». Будет выполнен метод `clone` того     // класса, которым является этот объект.     foreach (s in shapes) do       shapesCopy.add(s.clone())     // Переменная shapesCopy будет содержать точные     // копии элементов массива shapes.

Применимость

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

Такое часто бывает, если ваш код работает с объектами, поданными извне через какой-то общий интерфейс. Вы не можете привязаться к их классам, даже если бы хотели, так как их конкретные классы неизвестны.

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

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

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

Таким образом, вместо порождения объектов из подклассов, вы будете копировать существующие объекты-прототипы, в которых уже настроено внутреннее состояние. Это позволит избежать взрывного роста количества классов в программе и уменьшить её сложность.

Шаги реализации

Создайте интерфейс прототипов с единственным методом clone. Если у вас уже есть иерархия продуктов, метод клонирования можно объявить непосредственно в каждом из её классов.

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

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

Метод клонирования обычно состоит всего из одной строки: вызова оператора new с конструктором прототипа. Все классы, поддерживающие клонирование, должны явно определить метод clone, чтобы подать собственный класс в оператор new. В обратном случае, результатом клонирования окажется объект родительского класса.

Опционально, создайте центральное хранилище прототипов. В нём можно хранить вариации объектов, возможно даже одного класса, но по-разному настроенных.

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

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

Преимущества и недостатки

Позволяет клонировать объекты, не привязываясь к их конкретным классам.

Меньше повторяющегося кода инициализации объектов.

Ускоряет создание объектов.

Альтернатива созданию подклассов для конструирования сложных объектов.

Сложно клонировать составные объекты, имеющие ссылки на другие объекты.

Отношения с другими паттернами

Многие архитектуры начинаются с применения Фабричного метода (более простого и расширяемого через подклассы) и эволюционируют в сторону Абстрактной фабрики, Прототипа или Строителя (более гибких, но и более сложных).

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

Если Команду нужно копировать перед вставкой в историю выполненных команд, вам может помочь Прототип.

Архитектура, построенная на Компоновщиках и Декораторах, часто может быть улучшена за счёт внедрения Прототипа. Он позволяет клонировать сложные структуры объектов, а не собирать их заново.

Прототип не опирается на наследование, но ему нужна сложная операция инициализации. Фабричный метод наоборот, построен на наследовании, но не требует сложной инициализации.

Снимок иногда можно заменить Прототипом, если объект, чьё состояние требуется сохранять в истории, довольно простой, не имеет активных ссылок на внешние ресурсы, либо их можно легко восстановить.

Абстрактная фабрика, Строитель и Прототип могут быть реализованы при помощи Одиночки.

Одиночка

Также известен как: Singleton

Суть паттерна

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

Проблема

Одиночка решает сразу две проблемы (нарушая принцип единственной ответственности класса).

Гарантирует наличие единственного экземпляра класса. Чаще всего это полезно для доступа к какому-то общему ресурсу, например, базе данных.

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

Такое поведение невозможно реализовать с помощью обычного конструктора, так как конструктор класса всегда возвращает новый объект.

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

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

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

Интересно, что в наше время паттерн стал настолько известен, что теперь люди называют «Одиночкой» даже те классы, которые решают лишь одну из проблем, перечисленных выше.

Решение

Все реализации одиночки сводятся к тому, чтобы скрыть конструктор по умолчанию и создать публичный статический метод, который и будет контролировать жизненный цикл объекта-одиночки.

Если у вас есть доступ к классу-одиночке, значит, будет доступ и к этому статическому методу. Из какой точки кода вы бы его не вызвали, он всегда будет отдавать один и тот же объект.

Аналогия из жизни

Правительство государства — хороший пример одиночки. В государстве может быть только одно официальное правительство. Вне зависимости от того, кто конкретно заседает в правительстве, оно имеет глобальную точку доступа «Правительство страны N».

Структура

Одиночка определяет статический метод getInstance, который возвращает единственный экземпляр своего класса.

Конструктор одиночки должен быть скрыт от клиентов. Вызов метода getInstance должен быть единственным способом получить объект этого класса.

Псевдокод

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

Этот класс не имеет публичного конструктора, поэтому единственный способ получить его объект — это вызвать метод getInstance. Этот метод сохранит первый созданный объект и будет возвращать его при всех последующих вызовах.

class Database is   private field instance: Database   static method getInstance() is     if (this.instance == null) then       acquireThreadLock() and then         // На всякий случай, ещё раз проверим не был         // ли объект создан другим потоком, пока         // текущий ждал освобождения блокировки.         if (this.instance == null) then           this.instance = new Database()     return this.instance   private constructor Database() is     // Здесь может жить код инициализации подключения к     // серверу баз данных.     // ...   public method query(sql) is     // Все запросы к базе данных будут проходить через     // этот метод. Поэтому имеет смысл поместить сюда     // какую-то логику кеширования.     // ... class Application is   method main() is     Database foo = Database.getInstance()     foo.query("SELECT ...")     // ...     Database bar = Database.getInstance()     bar.query("SELECT ...")     // Переменная "bar" содержит тот же объект, что     // и переменная "foo".

Применимость

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

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

Когда вам хочется иметь больше контроля над глобальными переменными.

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

Тем не менее, в любой момент вы можете расширить это ограничение и позволить любое количество объектов-одиночек, поменяв код в одном месте (метод getInstance).

Шаги реализации

Добавьте в класс приватное статическое поле, которое будет содержать одиночный объект.

Объявите статический создающий метод, который будет использоваться для получения одиночки.

Добавьте «ленивую инициализацию» (создание объекта при первом вызове метода) в создающий метод одиночки.

Сделайте конструктор класса приватным.

В клиентском коде замените вызовы конструктора вызовами создающего метода.

Преимущества и недостатки

Гарантирует наличие единственного экземпляра класса.

Предоставляет к нему глобальную точку доступа.

Реализует отложенную инициализацию объекта-одиночки.

Нарушает принцип единственной ответственности класса.

Маскирует плохой дизайн.

Проблемы мультипоточности.

Требует постоянного создания Mock-объектов при юнит-тестирования.

Отношения с другими паттернами

Фасад можно сделать Одиночкой, так как обычно нужен только один объект-фасад.

Паттерн Легковес может напоминать Одиночку, если для конкретной задачи у вас получилось уменьшить количество объектов к одному. Но помните, что между паттернами есть два кардинальных отличия:

В отличие от Одиночки, вы можете иметь множество объектов-легковесов.

Объекты-легковесов должны быть неизменяемыми, тогда как объект-одиночки допускает изменение своего состояния.

Абстрактная фабрика, Строитель и Прототип могут быть реализованы при помощи Одиночки.

Структурные паттерны

Эти паттерны отвечают за построение удобных в поддержке иерархий классов.

Адаптер Adapter Позволяет объектам с несовместимыми интерфейсами работать вместе. Мост Bridge Разделяет один или несколько классов на две отдельные иерархии — абстракцию и реализацию, позволяя изменять их независимо друг от друга. Компоновщик Composite Позволяет сгруппировать объекты в древовидную структуру, а затем работать с ними так, если бы это был единичный объект. Декоратор Decorator Позволяет динамически добавлять объектам новую функциональность, оборачивая их в полезные «обёртки». Фасад Facade Предоставляет простой интерфейс к сложной системе классов, библиотеке или фреймворку. Легковес Flyweight Позволяет вместить бóльшее количество объектов в отведённую оперативной память за счёт экономного разделения общего состояния объектов между собой, вместо хранения одинаковых данных в каждом объекте. Заместитель Proxy Позволяет подставлять вместо реальных объектов специальные объекты-заменители. Эти объекты перехватывают вызовы к оригинальному объекту, позволяя сделать что-то до или после передачи вызова оригиналу.

Адаптер

Также известен как: Обёртка, Adapter

Суть паттерна

Адаптер — это структурный паттерн проектирования, который позволяет объектам с несовместимыми интерфейсами работать вместе.

Проблема

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

В какой-то момент вы решаете улучшить приложение, применив стороннюю библиотеку аналитики. Но вот беда, библиотека поддерживает только формат данных JSON, несовместимый с вашим приложением.

Подключить стороннюю библиотеку не выйдет из-за несовместимых форматов данных.

Вы смогли бы переписать библиотеку, чтобы та поддерживала формат XML. Но, во-первых, это может нарушить работу существующего кода, который уже зависит от библиотеки. А во-вторых, у вас может просто не быть доступа к её исходному коду.

Решение

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

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

Адаптеры могут не только переводить данные из одного формата в другой, но и помогать объектам с разными интерфейсами работать сообща. Это работает так:

Адаптер следует интерфейсу, который один объект ожидает от другого.

Когда первый объект вызывает методы адаптера, адаптер передаёт выполнение второму объекту, вызывая в нём те или иные методы в том порядке, который важен для второго объекта.

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

Программа может работать со сторонней библиотекой через адаптер.

Таким образом, в приложении биржевых котировок, вы могли бы создать класс XML_To_JSON_Adapter, который бы оборачивал класс библиотеки аналитики. Ваш код посылал бы запросы этому объекту в формате XML, а адаптер бы сначала транслировал входящие данные в формат JSON, а затем передавал бы их определённым методам библиотеки.

Аналогия из жизни

Содержимое чемоданов до и после поездки за границу.

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

Структура

Адаптер объектов

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

Клиент — это класс, который содержит существующую бизнес-логику программы.

Клиентский интерфейс описывает протокол, через который клиент может работать с другими классами.

Сервис – это какой-то полезный класс, обычно сторонний. Клиент не может использовать этот класс напрямую, так как сервис имеет непонятный ему интерфейс.

Адаптер — это класс, который может одновременно работать и с клиентом, и с сервисом. Он реализует клиентский интерфейс и содержит ссылку на объект сервиса. Адаптер получает вызовы от клиента через методы клиентского интерфейса, а затем переводит их в вызовы методов обёрнутого объекта в правильном формате.

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

Адаптер классов

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

Адаптер классов не нуждается во вложенном объекте, так как он одновременно наследует и существующий и сервисный интерфейс.

Псевдокод

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

Пример адаптации квадратных колышков и круглых отверстий.

Адаптер вычисляет наименьшую окружность, в которую можно вписать квадратный колышек и представляет его как круглый колышек с таким диаметром.

// Классы с совместимыми интерфейсами: КруглоеОтверстие // и КруглыйКолышек. class RoundHole is   constructor RoundHole(radius) { ... }   method getRadius is     // Вернуть радиус отверстия.   method fits(peg: RoundPeg) is     return this.getRadius() >= peg.radius() class RoundPeg is   constructor RoundPeg(radius) { ... }   method getRadius() is     // Вернуть радиус круглого колышка. // Устаревший несовместимый класс: КвадратныйКолышек. class SquarePeg is   constructor SquarePeg(width) { ... }   method getWidth() is     // Вернуть ширину квадратного колышка. // Адаптер позволяет использовать квадратные колышки и // круглые отверстия вместе. class SquarePegAdapter extends RoundPeg is   private field peg: SquarePeg   constructor SquarePegAdapter(peg: SquarePeg) is     this.peg = peg   method getRadius() is     // Вычислить половину диагонали квадратного колышка     // по теореме Пифагора.     return Math.sqrt(2 * Math.pow(peg.getWidth(), 2)) / 2 // Где-то в клиентском коде. hole = new RoundHole(5) rpeg = new RoundPeg(5) hole.fits(rpeg) // true small_sqpeg = new SquarePeg(2) large_sqpeg = new SquarePeg(5) hole.fits(small_sqpeg) // ошибка компиляции, несовместимые типы small_sqpeg_adapter = new SquarePegAdapter(small_sqpeg) large_sqpeg_adapter = new SquarePegAdapter(large_sqpeg) hole.fits(small_sqpeg_adapter) // true hole.fits(large_sqpeg_adapter) // false

Применимость

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

Адаптер позволяет создать объект-прокладку, который будет превращать вызовы приложения в формат, понятный стороннему классу.

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

Вы могли бы создать ещё один уровень подклассов, и добавить в них недостающую функциональность. Но при этом придётся дублировать один и тот же код в обеих ветках подклассов.

Более элегантное решение — поместить недостающую функциональность в адаптер и приспособить его для работы с суперклассом. Такой адаптер сможет работать со всеми подклассами иерархии. Это решение будет сильно напоминать паттерн Посетитель.

Шаги реализации

Убедитесь, что у вас есть два класса с неудобными интерфейсами:

полезный сервис — служебный класс, который вы не можете изменять (он либо сторонний, либо от него зависит другой код);

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

Опишите клиентский интерфейс, через который классы приложения смогли бы использовать сторонний класс.

Создайте класс адаптера, реализовав этот интерфейс.

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

Реализуйте все методы клиентского интерфейса в адаптере. Адаптер должен делегировать основную работу сервису.

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

Преимущества и недостатки

Отделяет и скрывает от клиента подробности преобразования различных интерфейсов.

Усложняет код программы за счёт дополнительных классов.

Отношения с другими паттернами

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

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

Адаптер предоставляет классу альтернативный интерфейс. Декоратор предоставляет расширенный интерфейс. Заместитель предоставляет тот же интерфейс.

Фасад задаёт новый интерфейс, тогда как Адаптер повторно использует старый. Адаптер оборачивает только один класс, а Фасад оборачивает целую подсистему. Кроме того, Адаптер позволяет двум существующим интерфейсам работать сообща, вместо того, чтобы задать полностью новый.

Мост, Стратегия и Состояние (а также слегка и Адаптер) имеют схожие структуры классов — все они построены на принципе «композиции», то есть делегирования работы другим объектам. Тем не менее, они отличаются тем, что решают разные проблемы. Помните, что паттерны — это не только рецепт построения кода определённым образом, но и описание проблем, которые привели к данному решению.

Мост

Также известен как: Bridge

Суть паттерна

Мост — это структурный паттерн проектирования, который разделяет один или несколько классов на две отдельные иерархии — абстракцию и реализацию, позволяя изменять их независимо друг от друга.

Проблема

Абстракция? Реализация?! Звучит пугающе! Чтобы понять, о чём идёт речь, давайте разберём очень простой пример.

У вас есть класс геометрических Фигур, который имеет подклассы Круг и Квадрат. Вы хотите расширить иерархию фигур по цвету, то есть иметь Красные и Синие фигуры. Но чтобы всё это объединить, вам придётся создать 4 комбинации подклассов вроде СиниеКруги и КрасныеКвадраты.

Количество подклассов растёт в геометрической прогрессии.

При добавлении новых видов фигур и цветов количество комбинаций будет расти в геометрической прогрессии. Чтобы добавить подкласс Треугольник, придётся создать сразу два новых класса под каждый цвет. После этого новый цвет потребует создания уже трёх классов, для всех видов фигур. Чем дальше, тем хуже.

Решение

Корень проблемы заключается в том, что мы пытаемся расширить классы сразу в двух независимых плоскостях — по виду и по цвету. Именно это приводит к разрастанию дерева классов.

Паттерн Мост предлагает заменить наследование делегированием. Для этого нужно выделить одну из таких «плоскостей» в отдельную иерархию и ссылаться на объект этой иерархии, вместо хранения его состояния и поведения внутри одного класса.

Размножение подклассов можно остановить, разбив классы на несколько иерархий.

Таким образом, мы можем сделать Цвет отдельным классом с подклассами Красный и Синий. Класс Фигур получит ссылку на объект Цвета и сможет делегировать ему работу, если потребуется. Такая связь и станет мостом между Фигурами и Цветом. При добавлении новых классов цветов, не потребуется трогать классы фигур и наоборот.

Абстракция и Реализация

Эти термины были введены в книге GoF 5Gang of Four / «Банда четырёх». Авторы книги Design Patterns: Elements of Reusable Object-Oriented Software -book. при описании Моста. На мой взгляд, они выглядят слишком академичными, делая описание паттерна сложнее, чем он есть на самом деле. Помня о примере с фигурами и цветами, давайте все же разберёмся, что имели в виду авторы паттерна.

Итак, «Абстракция» (или «интерфейс») — это образный слой управления чем-либо. Он не делает работу самостоятельно, а делегирует её слою «реализации» (иногда называемому «платформой»).

Только не путайте эти термины с интерфейсами или абстрактными классами из вашего языка программирования, это не одно и то же.

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

Вы можете развивать программу в двух разных направлениях:

иметь несколько различных интерфейсов (например, для простых пользователей и администраторов).

поддерживать много видов API (например, работать под Windows, Linux и MacOS).

Такая программа может выглядеть как один большой клубок кода, в котором намешаны условные операторы слоёв интерфейса и API операционных систем.

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

Вы можете попытаться структурировать этот хаос, создав для каждой вариаций интерфейса-платформы свои подклассы. Но такой подход приведёт к росту классов комбинаций, и с каждой новой платформой их будет всё больше.

Мы можем решить эту проблему, применив Мост. Паттерн предлагает распутать этот код, разделив его на две части:

Абстракцию: слой GUI приложения.

Реализацию: слой взаимодействия с операционной системой.

Один из вариантов кросс-платформенной архитектуры.

Абстракция будет делегировать работу одному из объектов-Реализаций. Реализации можно будет взаимозаменять, если все они будут иметь общий интерфейс.

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

Структура

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

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

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

Конкретные Реализации содержат платформо-зависимый код.

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

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

Псевдокод

В этом примере Мост разделяет монолитный код приборов и пультов на две части: приборы (выступают реализацией) и пульты управления ними (выступают абстракцией).

Пример разделения двух иерархий классов — приборов и пультов управления.

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

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

Клиентскому коду остаётся выбрать версию абстракции и реализации, с которым он хочет работать.

// Класс пультов имеет ссылку на устройство, которым // управляет. Методы этого класса делегируют работу методам // связанного устройства. class Remote is   protected field device: Device   constructor Remote(device: Device) is     this.device = device   method togglePower() is     if (device.isEnabled()) then       device.disable()     else       device.enable()   method volumeDown() is     device.setVolume(device.getVolume() - 10)   method volumeUp() is     device.setVolume(device.getVolume() + 10)   method channelDown() is     device.setChannel(device.getChannel() - 1)   method channelUp() is     device.setChannel(device.getChannel() + 1) // Вы можете расширять класс пультов не трогая // код устройств. class AdvancedRemote extends Remote is   method mute() is     device.setVolume(0) // Все устройства имеют общий интерфейс. Поэтому с ними // может работать любой пульт. interface Device is   method isEnabled()   method enable()   method disable()   method getVolume()   method setVolume(percent)   method getChannel()   method setChannel(channel) // Но каждое устройство имеет особую реализацию. class Tv implements Device is   // ... class Radio implements Device is   // ... // Где-то в клиентском коде. tv = new Tv() remote = new Remote(tv) remote.power() radio = new Radio() remote = new AdvancedRemote(radio)

Применимость

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

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

Мост позволяет разделить монолитный класс на несколько отдельных иерархий. После этого вы можете менять их код независимо друг от друга. Это упрощает работу над кодом и уменьшает вероятность внесения ошибок.

Когда класс нужно расширять в двух независимых плоскостях.

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

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

Мост позволяет заменять реализацию даже во время выполнения программы, так как конкретная реализация не «вшита» в класс абстракции.

Кстати, из-за этого пункта Мост часто путают со Стратегией. Обратите внимания, что у Моста этот пункт стоит на последнем месте по значимости, так как его главная задача — структурная.

Шаги реализации

Определите, существует ли в ваших классах два непересекающихся измерения. Это может быть функциональность/платформа, предметная-область/инфраструктура, фронт-энд/бэк-энд или интерфейс/реализация.

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

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

Для каждой платформы создайте свой класс конкретной реализации. Все они должны следовать общему интерфейсу, который мы выделили перед этим.

Добавьте в класс абстракции ссылку на объект реализации. Реализуйте методы абстракции, делегируя основную работу связанному объекту реализации.

Если у вас есть несколько вариаций абстракции, создайте для каждой из них свой подкласс.

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

Преимущества и недостатки

Позволяет строить платформо-независимые программы.

Скрывает лишние или опасные детали реализации от клиентского кода.

Реализует принцип открытости/закрытости.

Усложняет код программы за счёт дополнительных классов.

Отношения с другими паттернами

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

Мост, Стратегия и Состояние (а также слегка и Адаптер) имеют схожие структуры классов — все они построены на принципе «композиции», то есть делегирования работы другим объектам. Тем не менее, они отличаются тем, что решают разные проблемы. Помните, что паттерны — это не только рецепт построения кода определённым образом, но и описание проблем, которые привели к данному решению.

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

Паттерн Строитель может быть построен в виде Моста: директор будет играть роль абстракции, а строители — реализации.

Компоновщик

Также известен как: Дерево, Composite

Суть паттерна

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

Проблема

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

Например, есть два объекта — Продукт и Коробка. Коробка может содержать несколько Продуктов и других Коробок поменьше. Те, в свою очередь, тоже содержат либо Продукты, либо Коробки и так далее.

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

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

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

Решение

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

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

Компоновщик рекурсивно запускает действие по все элементы дерева от корня к листьям.

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

Аналогия из жизни

Пример армейской структуры.

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

Структура

Компонент определяет общий интерфейс для простых и составных компонентов дерева.

Лист – это простой элемент дерева, не имеющий ответвлений.

Из-за того, что им некому больше передавать выполнение, классы Листьев будут содержать большую часть полезного кода.

Контейнер (или «композит») — это составной элемент дерева. Он содержит набор дочерних компонентов, но ничего не знает об их типах. Это могут быть как простые компоненты-листья, так и другие компоненты-контейнеры. Но это не является проблемой, так как все дочерние элементы следуют общему интерфейсу.

Методы контейнера переадресуют основную работу своим дочерним компонентам, хотя и могут добавлять что-то своё к результату.

Клиент работает с деревом через общий интерфейс компонентов.

Благодаря этому, клиенту без разницы что перед ним находится — простой или составной компонент дерева.

Псевдокод

В этом примере Компоновщик помогает реализовать вложенные геометрические фигуры.

Пример редактора геометрических фигур.

Класс CompoundGraphic может содержать любое количество подфигур, включая такие же контейнеры, как он сам. Контейнер реализует те же методы, что и простые фигуры. Но вместо непосредственного действия, он передаёт вызовы всем вложенным компонентам, используя рекурсию. Затем он как бы «суммирует» результаты всех вложенных фигур.

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

// Общий интерфейс компонентов. interface Graphic is   method move(x, y)   method draw() // Простой компонент. class Dot implements Graphic is   field x, y   constructor Dot(x, y) { ... }   method move(x, y) is     this.x += x, this.y += y   method draw() is     // Нарисовать точку в координате X, Y. // Компоненты могут расширять другие компоненты. class Circle extends Dot is   field radius   constructor Circle(x, y, radius) { ... }   method draw() is     // Нарисовать окружность в координате X, Y и радиусом R. // Контейнер содержит операции добавления/удаления дочерних // компонентов. Все стандартные операции интерфейса // компонентов он делегирует каждому из // дочерних компонентов. class CompoundGraphic implements Graphic is   field children: array of Graphic   method add(child: Graphic) is     // Добавить компонент в список дочерних.   method remove(child: Graphic) is     // Убрать компонент из списка дочерних.   method move(x, y) is     foreach (child in children) do       child.move(x, y)   method draw() is     // 1. Для каждого дочернего компонента:     //    - Отрисовать компонент.     //    - Определить координаты максимальной границы.     // 2. Нарисовать пунктирную границу вокруг всей области. // Приложение работает единообразно как с единичными // компонентами, так и целыми группами компонентов. class ImageEditor is   method load() is     all = new CompoundGraphic()     all.add(new Dot(1, 2))     all.add(new Circle(5, 3, 10))     // ...   // Группировка выбранных компонентов в один   // сложный компонент.   method groupSelected(components: array of Graphic) is     group = new CompoundGraphic()     group.add(components)     all.remove(components)     all.add(group)     // Все компоненты будут отрисованы.     all.draw()

Применимость

Когда вам нужно представить древовидную структуру объектов.

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

Когда клиенты должны единообразно трактовать простые и составные объекты.

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

Шаги реализации

Убедитесь, что вашу бизнес-логику можно представить как древовидную структуру. Попытайтесь разбить её на простые элементы и контейнеры. Помните, что контейнеры могут содержать как простые элементы, так и другие контейнеры.

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

Создайте класс компонентов-листьев, не имеющих дальнейших ответвлений. Имейте в виду, что программа может содержать несколько видов таких классов.

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

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

Добавьте операции добавления и удаления дочерних элементов в класс контейнеров.

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

Преимущества и недостатки

Упрощает архитектуру клиента при работе со сложным деревом компонентов.

Облегчает добавление новых видов компонентов.

Создаёт слишком общий дизайн классов.

Отношения с другими паттернами

Строитель позволяет пошагово сооружать дерево Компоновщика.

Цепочку обязанностей часто используют вместе с Компоновщиком. В этом случае, запрос передаётся от дочерних компонентов к их родителям.

Вы можете обходить дерево Компоновщика, используя Итератор.

Вы можете выполнить какое-то действие над всем деревом Компоновщика при помощи Посетителя.

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

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

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

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

Архитектура, построенная на Компоновщиках и Декораторах, часто может быть улучшена за счёт внедрения Прототипа. Он позволяет клонировать сложные структуры объектов, а не собирать их заново.

Декоратор

Также известен как: Обёртка, Decorator

Суть паттерна

Декоратор — это структурный паттерн проектирования, который позволяет динамически добавлять объектам новую функциональность, оборачивая их в полезные «обёртки».

Проблема

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

Основой библиотеки является класс Notificator с методом send, который принимает на вход строку-сообщение и высылает её всем администраторам по электронной почте. Сторонняя программа должна создать и настроить этот объект, указав кому слать оповещения, а затем использовать его каждый раз, когда что-то случается.

Сторонние программы используют главный класс оповещений.

В какой-то момент стало понятно, что одних email-оповещений пользователям мало. Некоторые из пользователей хотели бы получать извещения о критических проблемах через SMS. Другие пользователи хотят получать их в виде сообщений Facebook. Корпоративные пользователи хотят видеть сообщения в Slack.

Каждый способ оповещения живёт в собственном подклассе.

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

Но затем кто-то резонно спросил, почему нельзя выбрать несколько видов оповещений сразу? Ведь если вдруг загорается ваш дом, вы бы хотели получить оповещения по всем каналам, верно?

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

Комбинаторный взрыв подклассов при совмещении способов оповещений.

Итак, нужен какой-то другой способ комбинировать поведения объектов, который не приводит к взрыву количества подклассов.

Решение

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

Он статичен. Вы не можете изменить поведение существующего объекта. Для этого вам надо создать новый объект, выбрав другой подкласс.

Он не разрешает наследовать поведение нескольких классов одновременно. Из-за этого вам приходится создавать множество подклассов-комбинаций для получения совмещённого поведения.

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

Наследование против Композиции

Декоратор имеет альтернативное название — «обёртка». Оно удачнее описывает суть паттерна: вы помещаете целевой объект в другой объект-обёртку, который запускает базовое поведение объекта, а затем добавляет к результату что-то своё.

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

В нашем примере с оповещениями, мы оставим в базовом классе простую отправку по электронной почте, а расширенные способы отправки сделаем декораторами.

Расширенные способы оповещения становятся декораторами.

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

Программа может составлять составные объекты из декораторов.

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

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

Аналогия из жизни

Одежду можно надевать слоями, получая комбинированный эффект.

Любая одежда — это аналог декоратора. Применяя декоратор, вы не меняете первоначальный класс и не создаёте дочерних классов. Так и с одеждой — надевая свитер, вы не перестаёте быть собой, но получаете новое свойство — защиту от холода. Вы можете пойти дальше и надеть сверху ещё один декоратор, плащ, чтобы защититься и от дождя.

Структура

Компонент задаёт общий интерфейс обёрток и оборачиваемых объектов.

Конкретный Компонент определяет класс оборачиваемых объектов. Он содержит какое-то базовое поведение, которое потом изменяют декораторы.

Базовый Декоратор хранит ссылку на вложенный объект-компонент. Им может быть как конкретный компонент, так и один из конкретных декораторов. Базовый декоратор делегирует все свои операции вложенному объекту. Дополнительное поведение будет жить в конкретных декораторах.

Конкретные Декораторы — это различные вариации декораторов, которые содержат добавочное поведение. Оно выполняется до или после вызова аналогичного поведения обёрнутого объекта.

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

Псевдокод

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

Пример шифрования и компрессии данных с помощью обёрток.

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

Декораторы, как и сам класс данных, имеют общий интерфейс. Поэтому клиентскому коду без разницы с чем работать.

// Общий интерфейс компонентов. interface DataSource is   method writeData(data)   method readData():data // Один из конкретных компонент, реализует // базовую функциональность. class FileDataSource implements DataSource is   constructor FileDataSource(filename) { ... }   method writeData(data) is     // Записать данные в файл.   method readData():data is     // Прочитать данные из файла. // Родитель всех декораторов содержит код обёртывания. class DataSourceDecorator implements DataSource is   protected field wrappee: DataSource   constructor DataSourceDecorator(source: DataSource) is     wrappee = source   method writeData(data) is     wrappee.writeData(data)   method readData():data is     return wrappee.readData() // Конкретные декораторы добавляют что-то своё к базовому // поведению обёрнутого компонента. class EncyptionDecorator extends DataSourceDecorator is   method writeData(data) is     // 1. Зашифровать поданные данные.     // 2. Передать зашифрованные данные в метод writeData     // обёрнутого объекта (wrappee).   method readData():data is     // 1. Получить данные из метода readData обёрнутого     // объекта (wrappee).     // 2. Расшифровать их, если они зашифрованы.     // 3. Вернуть результат. // Декорировать можно не только базовые компоненты, но и уже // обёрнутые объекты. class CompressionDecorator extends DataSourceDecorator is   method writeData(data) is     // 1. Запаковать поданные данные.     // 2. Передать запакованные данные в метод writeData     // обёрнутого объекта (wrappee).   method readData():data is     // 1. Получить данные из метода readData обёрнутого     // объекта (wrappee).     // 2. Распаковать их, если они запакованы.     // 3. Вернуть результат. // Вариант 1. Простой пример сборки и // использования декораторов. class Application is   method dumbUsageExample() is     source = new FileDataSource("somefile.dat")     source.writeData(salaryRecords)     // В файл были записаны чистые данные.     source = new CompressionDecorator(source)     source.writeData(salaryRecords)     // В файл были записаны сжатые данные.     source = new EncyptionDecorator(source)     // source — это связка из трёх объектов:     // Encryption > Compression > FileDataSource     source.writeData(salaryRecords)     // В файл были записаны сжатые и     // зашифрованные данные. // Вариант 2. Клиентский код, использующий внешний источник // данных. Класс SalaryManager ничего не знает о том как // именно будут считаны и записаны данные. Он получает уже // готовый источник данных. class SalaryManager is   field source: DataSource   constructor SalaryManager(source: DataSource) { ... }   method load() is     return source.readData()   method save() is     source.writeData(salaryRecords)   // ...Остальные полезные методы... // Приложение может по-разному собирать декорируемые // объекты, в зависимости от условий использования. class ApplicationConfigurator is   method configurationExample() is     source = new FileDataSource("salary.dat")     if (enabledEncryption)       source = new EncyptionDecorator(source)     if (enabledCompression)       source = new CompressionDecorator(source)     logger = new SalaryLogger(source)     salary = logger.load()   // ...

Применимость

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

Объекты помещают в обёртки, имеющие дополнительные поведения. Обёртки и сами объекты имеют одинаковый интерфейс, поэтому клиентам без разницы с чем работать — с обычным объектом или обёрнутым.

Когда нельзя расширить обязанности объекта с помощью наследования.

Во многих языках программирования есть ключевое слово final, которое может заблокировать наследование класса. Расширить такие классы можно только с помощью Декоратора.

Шаги реализации

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

Создайте интерфейс компонента, который описывал бы все общие методы как для основного компонента, так и для его дополнений.

Создайте класс конкретного компонента и поместите в него основную бизнес-логику.

Создайте базовый класс декораторов. Он должен иметь поле для хранения ссылки на вложенный объект-компонент. Все методы базового декоратора должны делегировать действие вложенному объекту.

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

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

Клиент берёт на себя ответственность за конфигурацию и порядок обёртывания объектов.

Преимущества и недостатки

Большая гибкость, чем у наследования.

Позволяет добавлять обязанности на лету.

Можно добавлять несколько новых обязанностей сразу.

Позволяет иметь несколько мелких объектов вместо одного объекта на все случаи жизни.

Трудно конфигурировать многократно обёрнутые объекты.

Обилие крошечных классов.

Отношения с другими паттернами

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

Адаптер предоставляет классу альтернативный интерфейс. Декоратор предоставляет расширенный интерфейс. Заместитель предоставляет тот же интерфейс.

Цепочка обязанностей и Декоратор имеют очень похожие структуры. Оба паттерна базируются на принципе рекурсивного выполнения операции через серию связанных объектов. Но есть и несколько важных отличий.

Обработчики в Цепочке обязанностей могут выполнять произвольные действия, независимые друг от друга, а также в любой момент прерывать дальнейшую передачу по цепочке. С другой стороны Декораторы расширяют какое-то определённое действие, не ломая интерфейс базовой операции и не прерывая выполнение остальных декораторов.

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

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

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

Архитектура, построенная на Компоновщиках и Декораторах, часто может быть улучшена за счёт внедрения Прототипа. Он позволяет клонировать сложные структуры объектов, а не собирать их заново.

Стратегия меняет поведение объекта «изнутри», а Декоратор изменяет его «снаружи».

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

Фасад

Также известен как: Facade

Суть паттерна

Фасад — это структурный паттерн проектирования, который предоставляет простой интерфейс к сложной системе классов, библиотеке или фреймворку.

Проблема

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

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

Решение

Фасад — это простой интерфейс работы со сложной подсистемой, содержащей множество классов. Фасад может иметь урезанный интерфейс, не имеющий 100% функциональности, которую можно достичь, используя сложную подсистему напрямую. Но он предоставляет именно те фичи, которые нужны клиенту, и скрывает все остальное.

Фасад полезен, если вы используете какую-то сложную библиотеку с множеством подвижных частей, но вам нужна только часть её возможностей.

К примеру, программа, заливающая видео котиков в социальные сети, может использовать профессиональную библиотеку сжатия видео. Но все что нужно клиентскому коду этой программы — простой метод encode(filename, format). Создав класс с таким методом, вы реализуете свой первый фасад.

Аналогия из жизни

Пример телефонного заказа.

Когда вы звоните в магазин и делаете заказ по телефону, сотрудник службы поддержки является вашим фасадом ко всем службам и отделам магазина. Он предоставляет вам упрощённый интерфейс к системе создания заказа, платёжной системе и отделу доставки.

Структура

Фасад предоставляет быстрый доступ к определённой функциональности подсистемы. Он «знает», каким классам нужно переадресовать запрос, и какие данные для этого нужны.

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

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

Классы подсистемы не знают о существовании фасада и работают друг с другом напрямую.

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

Псевдокод

В этом примере Фасад упрощает работу со сложным фреймворком видеоконвертации.

Пример изоляции множества зависимостей в одном фасаде.

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

// Классы сложного стороннего фреймворка конвертации видео. // Мы не контролируем этот код, поэтому не можем // его упростить. class VideoFile // ... class OggCompressionCodec // ... class MPEG4CompressionCodec // ... class CodecFactory // ... class BitrateReader // ... class AudioMixer // ... // Вместо этого, мы создаём Фасад — простой интерфейс для // работы со сложным фреймворком. Фасад не имеет всей // функциональности фреймворка, но зато скрывает его // сложность от клиентов. class VideoConverter is   method convert(filename, format):File is     file = new VideoFile(filename)     sourceCodec = new CodecFactory.extract(file)     if (format == "mp4")       distinationCodec = new MPEG4CompressionCodec()     else       distinationCodec = new OggCompressionCodec()     buffer = BitrateReader.read(filename, sourceCodec)     result = BitrateReader.convert(buffer, distinationCodec)     result = (new AudioMixer()).fix(result)     return new File(result) // Приложение не зависит от сложного фреймворка конвертации // видео. Кстати, если вы вдруг решите сменить фреймворк, // вам нужно будет переписать только класс фасада. class Application is   method main() is     convertor = new VideoConverter()     mp4 = convertor.convert("youtubevideo.ogg", "mp4")     mp4.save()

Применимость

Когда вам нужно представить простой или урезанный интерфейс к сложной подсистеме.

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

Когда вы хотите разложить подсистему на отдельные слои.

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

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

Шаги реализации

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

Создайте класс фасада, реализующий этот интерфейс. Он должен переадресовывать вызовы клиента нужным объектам подсистемы. Фасад должен будет позаботиться о том, чтобы правильно инициализировать объекты подсистемы.

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

Если ответственность фасада начинает размываться, подумайте о введении дополнительных фасадов.

Преимущества и недостатки

Изолирует клиентов от компонентов системы.

Уменьшает зависимость между подсистемой и клиентами.

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

Отношения с другими паттернами

Фасад задаёт новый интерфейс, тогда как Адаптер повторно использует старый. Адаптер оборачивает только один класс, а Фасад оборачивает целую подсистему. Кроме того, Адаптер позволяет двум существующим интерфейсам работать сообща, вместо того, чтобы задать полностью новый.

Абстрактная фабрика может быть использована вместо Фасада для того, чтобы скрыть платформо-зависимые классы.

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

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

Фасад создаёт упрощённый интерфейс к подсистеме, не внося в неё никакой добавочной функциональности. Сама подсистема не знает о существовании Фасада. Классы подсистемы общаются друг с другом напрямую.

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

Фасад можно сделать Одиночкой, так как обычно нужен только один объект-фасад.

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

Легковес

Также известен как: Приспособленец, Кэш, Flyweight

Суть паттерна

Легковес — это структурный паттерн проектирования, который позволяет вместить бóльшее количество объектов в отведённую оперативной память за счёт экономного разделения общего состояния объектов между собой, вместо хранения одинаковых данных в каждом объекте.

Проблема

На досуге вы решили написать небольшую игру-стрелялку, в которой игроки перемещаются по карте и стреляют друг в друга. Фишкой игры должна была стать реалистичная система частиц. Пули, снаряды, осколки от взрывов — всё это должно красиво летать и радовать взгляд.

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

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

В определённый момент, когда побоище на экране достигает кульминации, новые объекты частиц уже не помещаются в оперативную память компьютера и программа вылетает.

Решение

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

Остальное состояние объектов — координаты, вектор движения и скорость отличаются для всех частиц. Таким образом, эти поля можно рассматривать как контекст, в котором частица используется. А цвет и спрайт — это данные, не изменяющиеся во времени.

Неизменяемые данные объекта принято называть «внутренним состоянием». Все остальные данные — это «внешнее состояние».

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

В нашем примере с частицами, достаточно будет оставить всего три объекта с отличающимися спрайтами и цветом — для пуль, снарядов и осколков. Несложно догадаться, что такие облегчённые объекты называют «легковéсами».

Хранилище внешнего состояния

Но куда переедет внешнее состояние? Ведь кто-то должен его хранить. Чаще всего, его перемещают в контейнер, который управлял объектами до применения паттерна.

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

Но более элегантным решением было бы создать дополнительный класс-контекст, который связывал внешнее состояние с тем или иным легковесом. Это позволит обойтись только одним полем-массивом в классе контейнера.

«Но погодите-ка, нам потребуется столько же этих объектов, сколько было в самом начале!» — скажете вы и будете правы! Но дело в том, что объекты-контексты занимают намного меньше места, чем первоначальные. Ведь самые тяжёлые поля остались в легковесах (простите за каламбур), и сейчас мы будем ссылаться на эти объекты из контекстов вместо того, чтобы хранить дублирующее состояние.

Неизменяемость Легковесов

Так как объекты легковесов будут использованы в разных контекстах, вы должны быть уверены в том, что их состояние невозможно изменять после создания. Всё внутреннее состояние легковес должен получать через параметры конструктора. Он не должен иметь сеттеров и публичных полей.

Фабрика Легковесов

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

Главная польза от этого метода в том, чтобы искать уже созданные легковесы с таким же внутренним состоянием, что и требуемое. Если легковес находится, его можно повторно использовать. Если нет — просто создаём новый.

Обычно этот метод добавляют в контейнер легковесов либо создают отдельный класс-фабрику. Его даже можно сделать статическим и поместить в класс легковесов.

Структура

Вы всегда должны помнить о том, что Легковес применяется в программе, имеющей громадное количество одинаковых объектов. Этих объектов было так много, что они не помещались в доступную оперативную память без ухищрений. Паттерн разделил данные этих объектов на две части — контексты и легковесы.

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

Контекст содержит «внешнюю» часть состояния, уникальную для каждого объекта. Контекст связан с одним из объектов-легковесов, хранящих оставшееся состояние.

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

Клиент вычисляет или хранит контекст, то есть внешнее состояние легковесов. Для клиента легковесы выглядят как шаблонные объекты, которые можно настроить во время использования, передав контекст через параметры.

Фабрика легковесов управляет созданием и повторным использованием легковесов. Фабрика получает запросы, в которых указано желаемое состояние легковеса. Если легковес с таким состоянием уже создан, фабрика сразу его возвращает, а если нет — создаёт новый объект.

Псевдокод

В этом примере Легковес помогает сэкономить оперативную память при отрисовке на холсте миллионов объектов-деревьев.

Легковес выделяет повторяющуюся часть состояния из основного класса Tree и помещает его в дополнительный класс TreeType.

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

Таким образом, программа будет использовать намного меньше оперативной памяти, что позволит отрисовать больше деревьев на экране на том же железе.

// Этот класс-легковес содержит часть полей, которые // описывают деревья. Эти поля не уникальные для каждого // дерева в отличие, например, от координат — несколько // деревьев могут иметь ту же текстуру. //  // Поэтому мы переносим повторяющиеся данные в один // единственный объект и ссылаемся на него из множества // отдельных деревьев. class TreeType is   field name   field color   field texture   constructor TreeType(name, color, texture) { ... }   method draw(canvas, x, y) is     // 1. Создать картинку данного типа, цвета и текстуры.     // 2. Нарисовать картинку на холсте в позиции X, Y. // Фабрика легковесов решает когда нужно создать новый // легковес, а когда можно обойтись существующим. class TreeFactory is   static field treeTypes: collection of tree types   static method getTreeType(name, color, texture) is     type = treeTypes.find(name, color, texture)     if (type == null)       type = new TreeType(name, color, texture)       treeTypes.add(type)     return type // Контекстный объект, из которого мы выделили легковес // TreeType. В программе могут быть тысячи объектов Tree, // так как накладные расходы на их хранение совсем небольшие // — порядка трёх целых чисел (две координаты и ссылка). class Tree is   field x,y   field type: TreeType   constructor Tree(x, y, type) { ... }   method draw(canvas) is     type.draw(canvas, this.x, this.y) // Классы Tree и Forest являются клиентами Легковеса. При // желании их можно слить в один класс, если вам не нужно // расширять класс деревьев далее. class Forest is   field trees: collection of Trees   method plantTree(x, y, name, color, texture) is     type = TreeFactory.getTreeType(name, color, texture)     tree = new Tree(x, y, type)     trees.add(tree)   method draw(canvas) is     foreach (tree in trees) do       tree.draw(canvas)

Применимость

Когда не хватает оперативной памяти для поддержки всех нужных объектов.

Эффективность паттерна Легковес во многом зависит от того, как и где он используется. Применяйте этот паттерн, когда выполнены все перечисленные условия:

в приложении используется большое число объектов;

из-за этого высоки расходы оперативной памяти;

большую часть состояния объектов можно вынести за пределы их классов;

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

Шаги реализации

Разделите поля класса, который станет легковесом, на две части:

внутреннее состояние: значения этих полей одинаковы для большого числа объектов.

внешнее состояние (контекст): значения полей уникальны для каждого объекта.

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

Превратите поля внешнего состояния в аргументы методов, где эти поля использовались. Затем, удалите поля из класса.

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

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

Преимущества и недостатки

Экономит оперативную память.

Расходует процессорное время на поиск/вычисление контекста.

Усложняет код программы за счёт множества дополнительных классов.

Отношения с другими паттернами

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

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

Паттерн Легковес может напоминать Одиночку, если для конкретной задачи у вас получилось уменьшить количество объектов к одному. Но помните, что между паттернами есть два кардинальных отличия:

В отличие от Одиночки, вы можете иметь множество объектов-легковесов.

Объекты-легковесов должны быть неизменяемыми, тогда как объект-одиночки допускает изменение своего состояния.

Заместитель

Также известен как: Proxy

Суть паттерна

Заместитель — это структурный паттерн проектирования, который позволяет подставлять вместо реальных объектов специальные объекты-заменители. Эти объекты перехватывают вызовы к оригинальному объекту, позволяя сделать что-то до или после передачи вызова оригиналу.

Проблема

Для чего вообще контролировать доступ к объектам? Рассмотрим такой пример: у вас есть внешний ресурсоёмкий объект, который нужен не все время, а изредка.

Запросы к базе данных могут быть очень медленными.

Мы могли бы не создавать этот объект в самом начале программы, а только когда он кому-то реально понадобится. Каждый клиент объекта получил бы некий код отложенной инициализации. Но, вероятно, это привело бы к множественному дублированию кода.

В идеале, этот код хотелось бы поместить прямо в служебный класс, но это не всегда возможно. Например, код класса может находиться в закрытой сторонней библиотеке.

Решение

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

Заместитель «притворяется» базой данных, ускоряя работу за счёт ленивой инициализации и кеширования повторяющихся запросов.

Но в чём же здесь польза? Вы могли бы поместить в класс заместителя какую-то промежуточную логику, которая выполнялась бы до (или после) вызовов этих же методов в настоящем объекте. А благодаря одинаковому интерфейсу, объект заместитель можно передать в любой код, ожидающий сервисный объект.

Аналогия из жизни

Банковским чеком можно расплачиваться, как и наличностью.

Банковский чек — это заместитель пачки наличности. И чек, и наличность имеют общий интерфейс — ими можно оплачивать товары. Для покупателя польза в том, что не надо таскать с собой тонны наличности. А владелец магазина может превратить чек в зелёные бумажки, обратившись в банк.

Структура

Интерфейс сервиса определяет общий интерфейс для cервиса и заместителя. Благодаря этому, объект заместителя можно использовать там, где ожидается объект сервиса.

Сервис содержит полезную бизнес-логику.

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

Заместитель может сам отвечать за создание и удаление объекта сервиса.

Клиент работает с объектами через интерфейс сервиса. Благодаря этому, его можно «одурачить», подменив объект сервиса объектом заместителя.

Псевдокод

В этом примере Заместитель помогает добавить в программу механизм ленивой инициализации и кеширования тяжёлой служебной библиотеки интеграции с Youtube.

Пример кеширования результатов работы реального сервиса с помощью заместителя.

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

// Интерфейс удалённого сервиса. interface ThirdPartyYoutubeLib is   method listVideos()   method getVideoInfo(id)   method downloadVideo(id) // Конкретная реализация сервиса. Методы этого класса // запрашивают у ютуба различную информацию. Скорость // запроса зависит от интернет-канала пользователя и // состояния самого ютуба. Чем больше будет вызовов к // сервису, тем менее отзывчивой будет программа. class ThirdPartyYoutubeClass is   method listVideos() is     // Получить список видеороликов с помощью API Youtube.   method getVideoInfo(id) is     // Получить детальную информацию о каком-то видеоролике.   method downloadVideo(id) is     // Скачать видео с Youtube. // С другой стороны, можно кешировать запросы к ютубу и не // повторять их какое-то время, пока кеш не устареет. Но // внести этот код напрямую в сервисный класс нельзя, так // как он находится в сторонней библиотеке. Поэтому мы // поместим логику кеширования в отдельный класс-обёртку. Он // будет делегировать запросы к сервисному объекту, только // если нужно непосредственно выслать запрос. class CachedYoutubeClass implements ThirdPartyYoutubeLib is   private field service: ThirdPartyYoutubeClass   private field listCache, videoCache   field needReset   constructor CachedYoutubeClass(service: ThirdPartyYoutubeLib) is     this.service = service   method listVideos() is     if (listCache == null || needReset)       listCache = service.listVideos()     return listCache   method getVideoInfo(id) is     if (videoCache == null || needReset)       videoCache = service.getVideoInfo(id)     return videoCache   method downloadVideo(id) is     if (!downloadExists(id) || needReset)       service.downloadVideo(id) // Класс GUI, который использует сервисный объект. Вместо // реального сервиса, мы подсунем ему объект-заместитель. // Клиент ничего не заметит, так как заместитель имеет тот // же интерфейс, что и сервис. class YoutubeManager is   protected field service: ThirdPartyYoutubeLib   constructor YoutubeManager(service: ThirdPartyYoutubeLib) is     this.service = service   method renderVideoPage() is     info = service.getVideoInfo()     // Отобразить страницу видеоролика.   method renderListPanel() is     list = service.listVideos()     // Отобразить список превьюшек видеороликов.   method reactOnUserInput() is     renderVideoPage()     renderListPanel() // Конфигурационная часть приложения создаёт и передаёт // клиентам объект заместителя. class Application is   method init() is     youtubeService = new ThirdPartyYoutubeClass()     youtubeProxy = new CachedYoutubeClass(youtubeService)     manager = new YoutubeManager(youtubeProxy)     manager.reactOnUserInput()

Применимость

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

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

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

Прокси может проверять доступ при каждом вызове и передавать выполнение служебному объекту, если доступ разрешён.

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

В этом случае заместитель транслирует запросы клиента в вызовы по сети, в протоколе, понятном удалённому сервису.

Логирование запросов (логирующий прокси). Когда требуется хранить историю обращений к сервисному объекту.

Заместитель может сохранять историю обращения клиента к сервисному объекту.

Кеширование объектов («умная» ссылка). Когда нужно кешировать результаты запросов клиентов и управлять их жизненным циклом.

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

Кроме того, Заместитель может отслеживать, не менял ли клиент сервисный объект. Это позволит использовать объекты повторно и здóрово экономить ресурсы, особенно если речь идёт о больших прожорливых сервисах.

Шаги реализации

Определите интерфейс, который бы сделал заместитель и оригинальный объект взаимозаменяемыми.

Создайте класс заместителя. Он должен содержать ссылку на сервисный объект. Чаще всего, сервисный объект создаётся самим заместителем. В редких случаях, заместитель получает готовый сервисный объект от клиента через конструктор.

Реализуйте методы заместителя в зависимости от его предназначения. В большинстве случаев, проделав какую-то полезную работу, методы заместителя должны передать запрос сервисному объекту.

Подумайте о введении фабрики, которая решала бы какой из объектов создавать — заместитель или реальный сервисный объект. Но с другой стороны, эта логика может быть помещена в создающий метод самого заместителя.

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

Преимущества и недостатки

Позволяет контролировать сервисный объект незаметно для клиента.

Может работать, даже если сервисный объект ещё не создан.

Может контролировать жизненный цикл служебного объекта.

Усложняет программу за счёт дополнительных классов.

Увеличивает время отклика от сервиса.

Отношения с другими паттернами

Адаптер предоставляет классу альтернативный интерфейс. Декоратор предоставляет расширенный интерфейс. Заместитель предоставляет тот же интерфейс.

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

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

Поведенческие паттерны

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

Цепочка обязанностей Chain of Responsibility Позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик решает, может ли он обработать запрос сам и стоит ли передавать запрос дальше по цепи. Команда Command Превращает запросы в объекты, позволяя передавать их как аргументы при вызове методов, ставить запросы в очередь, логировать их, а также поддерживать отмену операций. Итератор Iterator Даёт возможность последовательно обходить элементы составных объектов, не раскрывая их внутреннего представления. Посредник Mediator Позволяет уменьшить связанность множества классов между собой, благодаря перемещению этих связей в один класс-посредник. Снимок Memento Позволяет делать снимки состояния объектов, не раскрывая подробностей их реализации. Затем снимки можно использовать, чтобы восстановить прошлое состояние объектов. Наблюдатель Observer Создаёт механизм подписки, позволяющий одним объектам следить и реагировать на события, происходящие в других объектах. Состояние State Позволяет объектам менять поведение в зависимости от своего состояния. Извне создаётся впечатление, что изменился класс объекта. Стратегия Strategy Определяет семейство схожих алгоритмов и помещает каждый из них в собственный класс. После чего, алгоритмы можно взаимозаменять прямо во время исполнения программы. Шаблонный метод Template method Определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Паттерн позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры. Посетитель Visitor Позволяет создавать новые операции, не меняя классы объектов, над которыми эти операции могут выполняться.

Цепочка обязанностей

Также известен как: CoR, Chain of Command, Chain of Responsibility

Суть паттерна

Цепочка обязанностей — это поведенческий паттерн проектирования, который позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик решает, может ли он обработать запрос сам и стоит ли передавать запрос дальше по цепи.

Проблема

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

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

Запрос проходит ряд проверок перед доступом в систему заказов.

На протяжении следующих нескольких месяцев вам пришлось добавить ещё несколько таких последовательных проверок.

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

Кто-то предложил фильтровать массовые отправки формы с одним и тем же логином, чтобы предотвратить подбор паролей ботами.

Кто-то заметил, что форму заказа неплохо бы доставать из кеша, если она уже была однажды показана.

Со временем код проверок становится всё более запутанным.

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

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

Решение

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

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

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

И последний штрих. Обработчик необязательно должен передавать запрос дальше. Причём эта особенность может быть использована по-разному.

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

Обработчики следуют в цепочке один за другим.

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

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

Цепочку можно выделить даже из дерева объектов.

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

Аналогия из жизни

Пример общения с поддержкой.

Вы купили новую видеокарту. Она автоматически определилась и заработала под Windows, но в вашей любимой Ubuntu «завести» её не удалось. Со слабой надеждой, вы звоните в службу поддержки.

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

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

Оператор перебрасывает звонок дежурному инженеру, изнывающему от скуки в своей каморке. Уж он-то знает, как вам помочь! Инженер рассказывает, где и как вы можете скачать подходящие драйвера, и как настроить их под Ubuntu. Запрос удовлетворён. Вы кладёте трубку.

Структура

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

Базовый обработчик — опциональный класс, который позволяет избавиться от дублирования одного и того же кода во всех конкретных обработчиках.

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

Конкретные обработчики содержат код обработки запросов. При получении запроса каждый обработчик решает, может ли он обработать запрос или нет, а также стоит ли передать его следующему объекту.

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

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

Псевдокод

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

Классы UI построены с помощью компоновщика, но каждый элемент «знает» о своём контейнере. Цепочку можно выстроить, пройдясь по всем контейнерам, в которые вложен элемент.

Графический интерфейс приложения обычно структурирован в виде дерева компонентов. Класс Диалог — это корень дерева, отображающий всё окно приложения. Диалог содержит Панели, которые, в свою очередь, могут содержать либо другие вложенные панели, либо простые компоненты вроде Кнопок.

Простые Компоненты могут показывать небольшие подсказки, если к ним привязан текст помощи. Но есть и более сложные компоненты, для которых этот способ слишком прост. Они определяют собственный способ отображения помощи.

Пример вызова контекстной помощи в цепочке объектов UI.

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

// Интерфейс обработчиков. interface ComponentWithContextualHelp is   method showHelp() is // Базовый класс простых компонентов. abstract class Component implements ContextualHelp is   field tooltipText: string   // Контейнер, содержащий компонент, служит в качестве   // следующего звена цепочки.   protected field container: Container   // Компонент показывает всплывающую подсказку, если   // задан текст подсказки. В обратном случае, он   // перенаправляет запрос контейнеру, если   // тот существует.   method showHelp() is     if (tooltipText != null)       // Показать подсказку.     else       container.showHelp() // Контейнеры могут включать в себя как простые компоненты, // так и другие контейнеры. Здесь формируются связи цепочки. // Класс унаследует метод showHelp от своего родителя. abstract class Container extends Component is   protected field children: array of Component   method add(child) is     children.add(child)     child.container = this // Примитивные компоненты может устраивать поведение помощи // по умолчанию... class Button extends Component is   // ... // Но сложные компоненты могут переопределять метод помощь // по-своему. Но если помощь не может быть предоставлена, // компонент вызовет базовую реализацию (см. // класс Component) class Panel extends Container is   field modalHelpText: string   method showHelp() is     if (modalHelpText != null)       // Показать модальное окно с помощью.     else       super.showHelp() // ...то же, что и выше... class Dialog extends Container is   field wikiPageURL: string   method showHelp() is     if (wikiPageURL != null)       // Открыть страницу Wiki в браузере.     else       super.showHelp() // Клиентский код. class Application is   // Каждое приложение конфигурирует цепочку по-своему.   method createUI() is     dialog = new Dialog("Budget Reports")     dialog.wikiPage = "http://..."     panel = new Panel(0, 0, 400, 800)     panel.modalHelpText = "This panel does..."     ok = new Button(250, 760, 50, 20, "OK")     ok.tooltipText = "This is a OK button that..."     cancel = new Button(320, 760, 50, 20, "Cancel")     // ...     panel.add(ok)     panel.add(cancel)     dialog.add(panel)   // Представьте что здесь произойдёт.   method onF1KeyPress() is     component = this.getComponentAtMouseCoords()     component.showHelp()

Применимость

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

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

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

Цепочка обязанностей позволяет запускать обработчики последовательно один за другим в определённом порядке.

Когда набор объектов, способных обработать запрос, должен задаваться динамически.

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

Шаги реализации

Создайте интерфейс обработчика и опишите в нём основной метод обработки.

Продумайте, в каком виде клиент должен передавать данные запроса в обработчик. Самый гибкий способ — превратить данные запроса в объект и передавать его целиком через параметры метода обработчика.

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

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

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

Один за другим создайте классы конкретных обработчиков и реализуйте в них методы обработки запросов. При получении запроса каждый обработчик должен решить:

Может он обработать запрос или нет?

Следует передать запрос следующему обработчику или нет?

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

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

Клиент должен знать о динамической природе цепочки и быть готов к таким случаям:

Цепочка может состоять из единственного объекта.

Запросы могут не достигать конца цепи.

Запросы могут достигать конца, оставаясь необработанными.

Преимущества и недостатки

Уменьшает зависимость между клиентом и обработчиками.

Реализует принцип единственной обязанности.

Реализует принцип открытости/закрытости.

Запрос может остаться никем не обработанным.

Отношения с другими паттернами

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

Цепочка обязанностей передаёт запрос последовательно через цепочку потенциальных получателей, ожидая, что какой-то из них обработает запрос.

Команда устанавливает косвенную одностороннюю связь от отправителей к получателям.

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

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

Цепочку обязанностей часто используют вместе с Компоновщиком. В этом случае, запрос передаётся от дочерних компонентов к их родителям.

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

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

Цепочка обязанностей и Декоратор имеют очень похожие структуры. Оба паттерна базируются на принципе рекурсивного выполнения операции через серию связанных объектов. Но есть и несколько важных отличий.

Обработчики в Цепочке обязанностей могут выполнять произвольные действия, независимые друг от друга, а также в любой момент прерывать дальнейшую передачу по цепочке. С другой стороны Декораторы расширяют какое-то определённое действие, не ломая интерфейс базовой операции и не прерывая выполнение остальных декораторов.

Команда

Также известен как: Действие, Транзакция, Command

Суть паттерна

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

Проблема

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

Все кнопки приложения унаследованы от одного класса.

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

Множество подклассов кнопок.

Но скоро стало понятно, что такой подход никуда не годится. Во-первых, получается очень много подклассов. Во-вторых, код кнопок, относящийся к графическому интерфейсу, начинает зависеть от классов бизнес-логики, которая довольно часто меняется.

Несколько классов дублирует одну и ту же функциональность.

Но самое обидное ещё впереди. Ведь некоторые операции, например «сохранить», можно вызывать из нескольких мест — нажав кнопку на панели управления, вызвав контекстное меню или просто нажав клавиши Ctrl+S. Когда в программе были только кнопки, код сохранения имелся только в подклассе SaveButton. Но теперь его придётся сдублировать ещё в два класса.

Решение

Хорошие программы обычно структурированы в виде слоёв. Самый распространённый пример — слои интерфейса и бизнес-логики. Первый всего лишь рисует красивую картинку для пользователя. Но когда нужно сделать что-то важное, интерфейс «просит» слой бизнес-логики заняться этим.

В реальности это выглядит так: один из объектов интерфейса напрямую вызывает метод одного из объектов бизнес-логики, передавая в него какие-то параметры.

Прямой доступ из UI в бизнес-логику.

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

Доступ из UI в бизнес-логику через команду.

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

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

Классы UI делегируют работу командам.

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

Объекты кнопок, используя общий интерфейс команд, будут по факту ссылаться на разные объекты команд и делегировать им работу при нажатии. А конкретные команды будут перенаправлять вызовы тем или иным объектам бизнес-логики.

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

Таким образом, команды станут настраиваемой прослойкой между объектами пользовательского интерфейса и бизнес-логики. И это лишь малая доля пользы, которую может принести паттерн Команда!

Аналогия из жизни

Пример заказа в ресторане.

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

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

В этом примере, вы являетесь отправителем, официант с блокнотом — командой, а шеф — получателем. Как и в паттерне, вы не соприкасаетесь напрямую с шефом. Вместо этого, вы отправляете заказ с официантом, который самостоятельно «настраивает» шефа на работу.

Структура

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

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

Конкретные команды реализуют различные запросы, следуя общему интерфейсу команд. Обычно, команда не делает всю работу самостоятельно, а лишь передаёт вызов получателю — определённому объекту бизнес-логики.

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

Получатель содержит бизнес-логику программы. В этой роли может выступать практически любой объект. Обычно, команды перенаправляют вызовы получателям. Но иногда, чтобы упростить программу, вы можете избавиться от получателей, слив их код в классы команд.

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

Псевдокод

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

Пример реализации отмены в текстовом редакторе.

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

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

// Абстрактная команда задаёт общий интерфейс для // всех команд. abstract class Command is   protected field app: Application   protected field editor: Editor   protected field backup: text   constructor Command(app: Application, editor: Editor) is     this.app = app     this.editor = editor   // Сохраняем состояние редактора.   method saveBackup() is     backup = editor.text   // Восстанавливаем состояние редактора.   method undo() is     editor.text = backup   // Главный метод команды остаётся абстрактным, чтобы   // каждая конкретная команда определила его по-своему.   // Метод должен возвратить true или false, в зависимости   // о того, изменила ли команда состояние редактора, а   // значит, нужно ли её сохранить в истории.   abstract method execute() // Конкретные команды. class CopyCommand extends Command is   // Команда копирования не записывается в историю, так   // как она не меняет состояние редактора.   method execute() is     app.clipboard = editor.getSelection()     return false class CutCommand extends Command is   // Команды, меняющие состояние редактора, сохраняют   // состояние редактора перед своим действием и   // сигнализируют об изменении, возвращая true.   method execute() is     saveBackup()     app.clipboard = editor.getSelection()     editor.deleteSelection()     return true class PasteCommand extends Command is   method execute() is     saveBackup()     editor.replaceSelection(app.clipboard)     return true // Отмена это тоже команда. class UndoCommand extends Command is   method execute() is     app.undo()     return false // Глобальная история команд — это стек. class CommandHistory is   private field history: array of Command   // Последний зашедший...   method push(c: Command) is     // Добавить команду в конец массива-истории.   // ...выходит первым.   method pop():Command is     // Достать последнюю команду из массива-истории. // Класс редактора содержит непосредственные операции над // текстом. Он отыгрывает роль получателя – команды // делегируют ему свои действия. class Editor is   field text: string   method getSelection() is     // Вернуть выбранный текст.   method deleteSelection() is     // Удалить выбранный текст.   method replaceSelection(text) is     // Вставить текст из буфера обмена в текущей позиции. // Класс приложения настраивает объекты для совместной // работы. Он выступает в роли отправителя — создаёт // команды, чтобы выполнить какие-то действия. class Application is   field clipboard: string   field editors: array of Editors   field activeEditor: Editor   field history: CommandHistory   // Код, привязывающий команды к элементам интерфейса   // может выглядеть примерно так.   method createUI() is     // ...     copy = function() {executeCommand(       new CopyCommand(this, activeEditor)) }     copyButton.setCommand(copy)     shortcuts.onKeyPress("Ctrl+C", copy)     cut = function() { executeCommand(       new CutCommand(this, activeEditor)) }     cutButton.setCommand(cut)     shortcuts.onKeyPress("Ctrl+X", cut)     paste = function() { executeCommand(       new PasteCommand(this, activeEditor)) }     pasteButton.setCommand(paste)     shortcuts.onKeyPress("Ctrl+V", paste)     undo = function() { executeCommand(       new UndoCommand(this, activeEditor)) }     undoButton.setCommand(undo)     shortcuts.onKeyPress("Ctrl+Z", undo)   // Запускаем команду и проверяем, надо ли добавить её   // в историю.   method executeCommand(command) is     if (command.execute)       history.push(command)   // Берём последнюю команду из истории и заставляем её   // все отменить. Мы не знаем конкретный тип команды, но   // это и не важно, так как каждая команда знает как   // отменить своё действие.   method undo() is     command = history.pop()     if (command != null)       command.undo()

Применимость

Когда вы хотите параметризовать объекты выполняемым действием.

Команда превращает операции в объекты. А объекты можно передавать, хранить и взаимозаменять внутри других объектов.

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

Когда вы хотите ставить операции в очередь, выполнять их по расписанию или передавать по сети.

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

Когда вам нужна операция отмены.

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

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

Этот способ имеет две особенности. Во-первых, точное состояние объектов не так-то просто сохранить, ведь часть его может быть приватным. Но с этим может помочь справиться паттерн Снимок.

Во-вторых, копии состояния могут занимать довольно много оперативной памяти. Поэтому иногда можно прибегнуть к альтернативной реализации, когда вместо восстановления старого состояния, команда выполняет обратное действие. Недостаток этого способа в сложности (а иногда и невозможности) реализации обратного действия.

Шаги реализации

Создайте общий интерфейс команд и определите в нём метод запуска.

Один за другим создайте классы конкретных команд. В каждом классе должно быть поле для хранения ссылки на один или несколько объектов-получателей, которым команда будет перенаправлять основную работу.

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

И наконец, реализуйте основной метод команды, вызывая в нём те или иные методы получателя.

Добавьте в классы отправителей поля для хранения команд. Объект-отправитель должен принимать готовый объект команды извне через конструктор, либо через сеттер команды.

Измените основной код отправителей так, чтобы они делегировали выполнение действия команде.

Порядок инициализации объектов должен выглядеть так:

Создаём объекты получателей.

Создаём объекты команд, связав их с получателями.

Создаём объекты отправителей, связав их с командами.

Преимущества и недостатки

Убирает прямую зависимость между объектами, вызывающими операции и объектами, которые их непосредственно выполняют.

Позволяет реализовать простую отмену и повтор операций.

Позволяет реализовать отложенный запуск команд.

Позволяет собирать сложные команды из простых.

Реализует принцип открытости/закрытости.

Усложняет код программы за счёт дополнительных классов.

Отношения с другими паттернами

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

Цепочка обязанностей передаёт запрос последовательно через цепочку потенциальных получателей, ожидая, что какой-то из них обработает запрос.

Команда устанавливает косвенную одностороннюю связь от отправителей к получателям.

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

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

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

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

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

Команда и Стратегия похожи по духу, но отличаются масштабом и применением:

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

С другой стороны, Стратегия описывает разные способы сделать одно и то же действие, позволяя взаимозаменять эти способы в каком-то объекте контекста.

Если Команду нужно копировать перед вставкой в историю выполненных команд, вам может помочь Прототип.

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

Итератор

Также известен как: Iterator

Суть паттерна

Итератор — это поведенческий паттерн проектирования, который даёт возможность последовательно обходить элементы составных объектов, не раскрывая их внутреннего представления.

Проблема

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

Разные типы коллекций.

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

Но как бы ни была структурирована коллекция, пользователь должен иметь возможность последовательно обходить её элементы, чтобы проделывать с ними какие-то действия.

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

Одну и ту же коллекцию можно обходить разными способами.

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

Решение

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

Итераторы содержат код обхода коллекции. Одну коллецию могут обходить сразу несколько итераторов.

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

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

Аналогия из жизни

Варианты прогулок по Риму.

Вы планируете полететь в Рим и обойти все достопримечательности за пару дней. Но приехав, вы можете долго петлять узкими улочками, пытаясь найти Колизей. Если у вас ограниченный бюджет — не беда. Вы можете воспользоваться виртуальным гидом, скачанным на телефон, который позволит отфильтровать только интересные вам точки. А можете плюнуть и нанять локального гида, который хоть и обойдётся в копеечку, но знает город как свои пять пальцев и сможет посвятить вас во все городские легенды.

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

Структура

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

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

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

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

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

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

Псевдокод

В этом примере паттерн Итератор используется для реализации обхода нестандартной коллекции, которая инкапсулирует доступ к социальному графу Facebook. Коллекция предоставляет несколько итераторов, которые могут по-разному обходить профиля людей.

Пример обхода социальных профилей через итератор.

Так, итератор друзей перебирает всех друзей профиля, а итератор коллег — фильтрует друзей по принадлежности к компании профиля. Все итераторы реализуют общий интерфейс, который позволяет клиентам работать с профилями, не вникая в детали работы с социальной сетью (например, авторизацию, отправку REST-запросов и т.д.)

Кроме того, Итератор избавляет код от привязки к конкретным классам коллекций. Это позволяет добавить поддержку другого вида коллекций (например, LinkedIn), не меняя клиентский код, который работает с итераторами и коллекциями.

// Общий интерфейс коллекций должен определить фабричный // метод для производства итератора. Можно определить сразу // несколько методов, чтобы дать пользователям различные // варианты обхода одной и той же коллекции. interface SocialNetwork is   method createFriendsIterator(profileId): ProfileIterator   method createCoworkersIterator(profileId): ProfileIterator // Конкретная коллекция знает объекты каких итераторов // нужно создавать. class Facebook implements SocialNetwork is   // ... Основной код коллекции ...   // Код получения нужного итератора.   method createFriendsIterator(profileId) is     return new FacebookIterator(this, profileId, "friends")   method createCoworkersIterator(profileId) is     return new FacebookIterator(this, profileId, "coworkers") // Общий интерфейс итераторов. interface ProfileIterator is   method getNext(): Profile   method hasMore(): bool // Конкретный итератор. class FacebookIterator implements ProfileIterator is   // Итератору нужна ссылка на коллекцию, которую   // он обходит.   private field facebook: Facebook   private field profileId, type: string   // Но каждый итератор обходит коллекцию независимо от   // остальных, поэтому он содержит информацию о текущей   // позиции обхода.   private field currentPosition   private field cache: array of Profile   constructor FacebookIterator(facebook, profileId, type) is     this.facebook = network     this.profileId = profileId     this.type = type   private method lazyInit() is     if (cache == null)       cache = facebook.sendSophisticatedSocialGraphRequest(profileId, type)   // Итератор реализует методы базового   // интерфейса по-своему.   method getNext() is     if (hasMore())       currentPosition++       return cache[currentPosition]   method hasMore() is     lazyInit()     return cache.length < currentPosition // Вот ещё полезная тактика: мы можем передавать объект // итератора вместо коллекции в клиентские классы. При таком // подходе, клиентский код не будет иметь доступа к // коллекциям, а значит его не будет волновать подробности // их реализаций. Ему будет доступен только общий // интерфейс итераторов. class SocialSpammer is   method send(iterator: ProfileIterator, message: string) is     while (iterator.hasNext())       profile = iterator.getNext()       System.sendEmail(profile.getEmail(), message) // Класс приложение конфигурирует классы как захочет. class Application is   field network: SocialNetwork   field spammer: SocialSpammer   method config() is     if working with Facebook       this.network = new Facebook()     if working with LinkedIn       this.network = new LinkedIn()     this.spammer = new SocialSpammer()   method sendSpamToFriends(profile) is     iterator = network.createFriendsIterator(profile.getId())     spammer.send(iterator, "Very important message")   method sendSpamToCoworkers(profile) is     iterator = network.createCoworkersIterator(profile.getId())     spammer.send(iterator, "Very important message")

Применимость

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

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

Когда вам нужно иметь несколько вариантов обхода одной и той же структуры данных.

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

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

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

Шаги реализации

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

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

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

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

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

Преимущества и недостатки

Упрощает классы хранения данных.

Позволяет реализовать различные способы обхода структуры данных.

Позволяет одновременно перемещаться по структуре данных в разные стороны.

Неоправдан, если можно обойтись простым циклом.

Отношения с другими паттернами

Вы можете обходить дерево Компоновщика, используя Итератор.

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

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

Посетитель можно использовать совместно с Итератором. Итератор будет отвечать за обход структуры данных, а Посетитель — за выполнение действий над каждым её компонентом.

Посредник

Также известен как: Intermediary, Controller, Mediator

Суть паттерна

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

Проблема

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

Беспорядочные связи между элементами пользовательского интерфейса.

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

Код элементов нужно трогать при измении каждого диалога.

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

Решение

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

В нашем примере посредником мог бы стать диалог. Скорее всего, класс диалога и так знает, из каких компонентов состоит. Поэтому никаких новых связей добавлять в него не придётся.

Элементы интерфейса общаются через посредника.

Основные изменения произойдут внутри отдельных компонентов диалога. Если раньше при получении клика от пользователя, объект кнопки сам проверял значения полей диалога, то теперь его единственной обязанностью будет сообщить диалогу о том, что произошёл клик. Получив извещение, диалог выполнит все необходимые проверки полей. Таким образом, вместо нескольких зависимостей от остальных элементов, кнопка получит только одну — от самого диалога.

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

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

Аналогия из жизни

Самолёты общаются не напрямую, а через диспетчера.

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

Важно понимать, что диспетчер не нужен во время всего полёта. Он задействован только в зоне аэропорта, когда нужно координировать взаимодействие многих самолётов.

Структура

Компоненты — это разнородные объекты, содержащие бизнес-логику программы. Каждый компонент хранит ссылку на объект посредника, но работает с ним только через абстрактный интерфейс посредников. Благодаря этому, компоненты можно повторно использовать в другой программе, связав их с посредником другого типа.

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

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

Компоненты не должны общаться напрямую друг с другом. Если в компоненте происходит важное событие, влияющее на других, он должен оповестить своего посредника. А тот, в свою очередь, самостоятельно передаст вызов другим компонентам, если это потребуется. При этом компонент-отправитель не знает, кто обработает его запрос, а компонент-получатель не знает, кто его прислал.

Псевдокод

В этом примере Посредник помогает избавиться от зависимостей между классами различных элементов UI — кнопками, чекбоксами и надписями.

Пример структурирования классов UI-диалогов.

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

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

// Общий интерфейс посредников. interface Mediator is   method notify(sender: Component, event: string) // Конкретный посредник. Все связи между конкретными // компонентами переехали в код посредника. Он получает // извещения от своих компонентов и знает как на // них реагировать. class AuthenticationDialog implements Mediator is   private field title: string   private field loginOrRegisterChkBx: Checkbox   private field loginUsername, loginPassword: Textbox   private field registrationUsername, registrationPassword   private field registrationEmail: Textbox   private field okBtn, cancelBtn: Button   constructor AuthenticationDialog() is     // Здесь нужно создать объекты всх компонентов, подав     // текущий объект-псоредник в их конструктор.   // Когда что-то случается с компонентом, он шлёт   // посреднику оповещение. После получения извещения,   // посредник может либо сделать что-то самостоятельно,   // либо перенаправить запрос другому компоненту.   method notify(sender, event) is     if (sender == loginOrRegisterChkBx and event == "check")       if (loginOrRegisterChkBx.checked)         title = "Log in"         // 1. Показать компоненты формы входа.         // 2. Скрыть компоненты формы регистрации.       else         title = "Register"         // 1. Показать компоненты формы регистрации.         // 2. Скрыть компоненты формы входа.     if (sender == okBtn && event == "click")       if (loginOrRegister.checked)         // Попробовать найти пользователя с данными из         // формы логина.         if (!found)           // Показать ошибку над формой логина.       else         // 1. Создать пользовательский аккаунт с данными         // из формы регистрации.         // 2. Авторизировать этого пользователя.     // ... // Классы компонентов общаются с посредниками через их общий // интерфейс. Благодаря этому, одни и те же компоненты можно // использовать в разных посредниках. class Component is   field dialog: Mediator   constructor Component(dialog) is     this.dialog = dialog   method click() is     dialog.notify(this, "click")   method keypress() is     dialog.notify(this, "keypress") // Конкретные компоненты никак не связаны между собой. У них // есть только один канал общения – через отправку // уведомлений посреднику. class Button extends Component is   // ... class Textbox extends Component is   // ... class Checkbox extends Component is   method check() is     dialog.notify(this, "check")   // ...

Применимость

Когда вам сложно менять некоторые классы из-за множества хаотичных связей с другими классами.

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

Когда вы не можете повторно использовать класс, поскольку он зависит от уймы других классов.

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

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

Если раньше изменение отношений в одном компоненте могли повлечь за собой снежный ком изменений в каждом другом компоненте, то теперь вам достаточно создать подкласс посредника и поменять в нём связи между компонентами.

Шаги реализации

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

Создайте общий интерфейс Посредников и опишите в нём методы для взаимодействия с Компонентами. В простейшем случае достаточно одного метода для получения оповещений от компонентов.

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

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

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

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

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

Преимущества и недостатки

Устраняет зависимости между компонентами, позволяя повторно их использовать.

Упрощает взаимодействие между компонентами.

Централизует управление в одном месте.

Посредник может сильно раздуться.

Отношения с другими паттернами

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

Цепочка обязанностей передаёт запрос последовательно через цепочку потенциальных получателей, ожидая, что какой-то из них обработает запрос.

Команда устанавливает косвенную одностороннюю связь от отправителей к получателям.

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

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

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

Фасад создаёт упрощённый интерфейс к подсистеме, не внося в неё никакой добавочной функциональности. Сама подсистема не знает о существовании Фасада. Классы подсистемы общаются друг с другом напрямую.

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

Разница между Посредником и Наблюдателем не всегда очевидна. Чаще всего они выступают как конкуренты, но иногда могут работать вместе.

Цель Посредника — убрать обоюдные зависимости между компонентами системы. Вместо этого они становятся зависимыми от самого посредника. С другой стороны, цель Наблюдателя — обеспечить динамическую одностороннюю связь, в которой одни объекты косвенно зависят от других.

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

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

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

Снимок

Также известен как: Хранитель, Memento

Суть паттерна

Снимок — это поведенческий паттерн проектирования, который позволяет делать снимки состояния объектов, не раскрывая подробностей их реализации. Затем снимки можно использовать, чтобы восстановить прошлое состояние объектов.

Проблема

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

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

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

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

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

Как команде создать снимок состояния редактора, если все его поля приватные?

Но это ещё не все. Давайте теперь рассмотрим сами копии состояния. Из чего состоит состояние редактора? Даже самые примитивные редакторы требуют нескольких полей для хранения текущего открытого текста, позиции курсора и прокрутки экрана. Чтобы сделать копию состояния, вам нужно записать значения всех этих полей в некий «контейнер».

Скорее всего, вам понадобится хранить массу таких «контейнеров», поэтому удобней всего сделать их объектами одного класса. Этот класс должен иметь массу полей и практически никаких методов. Чтобы другие классы смогли записывать и читать из него данные, вам придётся сделать его поля публичными. Но это приведёт к той же проблеме, что и с открытым классом редактора. Другие классы станут зависимыми от любых изменений в классе редактора.

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

Решение

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

Паттерн Снимок поручает создание копии состояния объекта самому объекту, который этим состоянием владеет. Вместо того чтобы делать снимок «извне», наш редактор сам сделает копию своих полей — ведь ему доступны все поля, даже приватные.

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

Снимок полностью открыт для создателя, но лишь частично открыт для опекунов.

Эта схема позволяет создателям производить снимки и отдавать их для хранения другим объектам, называемым «опекунами». Опекунам будет доступен только ограниченный интерфейс снимка, поэтому они никак не смогут повлиять на внутренности самого снимка. В нужный момент, опекун может попросить создателя восстановить своё состояние, передав в него соответствующий снимок.

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

Структура

Классическая реализация на вложенных классах

Классическая реализация паттерна полагается на механизм вложенных классов, которые доступны только в некоторых языках программирования (C++, C#, Java).

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

Снимок — это простой объект данных, содержащий состояние создателя. Надёжней всего сделать объекты снимков неизменяемыми и передавать в них состояние только через конструктор.

Опекун должен знать, когда делать снимок создателя и когда его нужно восстанавливать.

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

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

Реализация с промежуточным пустым интерфейсом

Подходит для языков, не имеющих механизма вложенных классов (PHP).

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

Благодаря этому достигается тот же эффект, что и в классической реализации. Создатель имеет полный доступ к снимку, а опекун — нет.

Снимки с повышенной защитой

Когда нужно полностью исключить доступ к состоянию Создателей и Снимков.

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

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

Снимки теперь связаны с теми создателями, из которых они сделаны. Они по-прежнему получают состояние через конструктор. Благодаря близкой связи между классами, снимки знают, как восстановить состояние своих создателей.

Псевдокод

В этом примере паттерн Снимок используется совместно с паттерном Команда и позволяет хранить резервные копии сложного состояния текстового редактора и, если потребуется, восстанавливать его.

Пример сохранения снимков состояния текстового редактора.

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

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

// Класс создателя должен иметь специальный метод, который // сохраняет состояние создателя в новом объекте-снимке. class Editor is   private field text, curX, curY, selectionWidth   method setText(text) is     this.text = text   method setCursor(x, y) is     this.curX = curX     this.curY = curY   method setSelectionWidth(width) is     this.selectionWidth = width   method createSnapshot(): EditorState is     // Снимок — неизменяемый объект, поэтому Создатель     // передаёт все своё состояние через     // параметры конструктора.     return new Snapshot(this, text, curX, curY, selectionWidth) // Снимок хранит прошлое состояние редактора. class Snapshot is   private field editor: Editor   private field text, curX, curY, selectionWidth   constructor Snapshot(editor, text, curX, curY, selectionWidth) is     this.editor = editor     this.text = text     this.curX = curX     this.curY = curY     this.selectionWidth = selectionWidth   // В нужный момент, владелец снимка может восстановить   // состояние редактора.   method restore() is     editor.setText(text)     editor.setCursor(curX, curY)     editor.setSelectionWidth(selectionWidth) // Опекуном может выступать класс команд (см. паттерн // Команда). В этом случае, команда сохраняет снимок // получателя перед тем, как выполнить действие. А при // отмене, возвращает получателя в предыдущее состояние. class Command is   private field backup: Snapshot   method makeBackup() is     backup = editor.saveState()   method undo() is     if (backup != null)       backup.restore()   // ...

Применимость

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

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

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

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

Шаги реализации

Определите класс создателя, объекты которого должны создавать снимки своего состояния.

Создайте класс снимка и опишите в нём все те же поля, которые имеются в оригинальном классе-создателе.

Сделайте объекты снимков неизменяемыми. Они должны получать начальные значения только один раз, через свой конструктор.

Если ваш язык программирования это позволяет, сделайте класс снимка вложенным в класс создателя.

Если нет, извлеките из класса снимка пустой интерфейс, который будет доступен остальным объектам программы. Впоследствии вы можете добавить некоторые вспомогательные методы в этот интерфейс, дающие доступ к метаданным снимка, однако прямой доступ к данным создателя должен быть исключён.

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

Сигнатура метода должна возвращать снимки через ограниченный интерфейс, если он у вас есть. Сам класс должен работать с конкретным классом снимка.

Добавьте в класс создателя метод восстановления из снимка. Что касается привязки к типам, руководствуйтесь той же логикой, что и в пункте 4.

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

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

Преимущества и недостатки

Не нарушает инкапсуляции исходного объекта.

Упрощает структуру исходного объекта. Ему не нужно хранить историю версий своего состояния.

Требует много памяти, если клиенты слишком часто создают снимки.

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

В некоторых языках (например, PHP, Python, JavaScript) сложно гарантировать, чтобы только исходный объект имел доступ к состоянию снимка.

Отношения с другими паттернами

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

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

Снимок иногда можно заменить Прототипом, если объект, чьё состояние требуется сохранять в истории, довольно простой, не имеет активных ссылок на внешние ресурсы, либо их можно легко восстановить.

Наблюдатель

Также известен как: Издатель-Подписчик, Слушатель, Observer

Суть паттерна

Наблюдатель — это поведенческий паттерн проектирования, который создаёт механизм подписки, позволяющий одним объектам следить и реагировать на события, происходящие в других объектах.

Проблема

Представьте, что у вас есть два объекта: Покупатель и Магазин. В магазин вот-вот должны завезти новый товар, который интересен покупателю.

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

Постоянное посещение магазинга или спам?

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

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

Решение

Давайте будем называть объекты, которые содержат интересное состояние Издателями. А другие объекты, которым интересно это состояние давайте звать Подписчиками.

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

Подписка на события.

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

Для издателя не важно, какого конкретно подписчика он оповещает, так как все подписчики договорились иметь один и тот же метод оповещения, то есть иметь общий интерфейс.

Оповещения о событиях.

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

Аналогия из жизни

Подписка на газеты и их доставка.

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

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

Структура

Издатель владеет внутренним состоянием, изменение которого интересно для подписчиков. Он содержит механизм подписки — список подписчиков, а также методы подписки/отписки.

Когда внутреннее состояние издателя меняется, он оповещает своих подписчиков. Для этого издатель проходит по списку подписчиков и вызывает их метод оповещения, заданный в интерфейсе подписчика.

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

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

По приходу оповещения, подписчику нужно получить обновлённое состояние издателя. Издатель может передать это состояние через параметры метода оповещения. Более гибкий вариант — передавать через параметры весь объект издателя, чтобы подписчик сам мог получить требуемые данные. Как вариант, подписчик может постоянно хранить ссылку на объект издателя, переданный ему в конструкторе.

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

Псевдокод

В этом примере Наблюдатель позволяет объекту текстового редактора оповещать другие объекты об изменениях своего состояния.

Пример оповещения объектов о событиях в других объектах.

Список подписчиков составляется динамически, объекты могут, как подписываться на определённые события, так и отписываться от них прямо во время выполнения программы.

В этой реализации, редактор не ведёт список подписчиков сам, а делегирует это вложенному объекту. Это даёт возможность использовать механизм подписки и в других объектах программы, а не только в классе редактора. Таким образом, паттерн Наблюдатель позволяет динамически настраивать обработчики тех или иных событий, происходящих с объектом.

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

// Базовый класс-издатель. Содержит код управления // подписчиками и их оповещения. class EventManager is   private field listeners: hash map of event types and listeners   method subscribe(eventType, listener) is     listeners.add(eventType, listener)   method unsubscribe(eventType, listener) is     listeners.remove(eventType, listener)   method notify(eventType, data) is     foreach (listener in listeners.of(eventType)) do       listener.update(data) // Конкретный класс издатель, содержащий интересную для // других компонентов бизнес-логику. Мы могли бы сделать его // прямым потомком EventManager, но в реальной жизни это не // всегда возможно (например, если вы у класса уже есть // родитель). Поэтому здесь мы подключаем механизм подписки // при помощи композиции. class Editor is   private field events: EventManager   private field file: File   constructor Editor() is     events = new EventManager()   // Методы бизнес-логики, которые оповещают подписчиков   // об изменениях.   method openFile(path) is     this.file = new File(path)     events.notify("open", file.name)   method saveFile() is     file.write()     events.notify("save", file.name)   // ... // Общий интерфейс подписчиков. Во многих языках, имеющих // функциональный типы, можно обойтись без этого интерфейса // и конкретных классов, заменив объекты подписчиков // функциями. interface EventListener is   method update(filename) // Набор конкретных подписчиков. Они реализуют добавочную // функциональность, реагируя на извещения от издателя. class LoggingListener is   private field log: File   private field message   constructor LoggingListener(log_filename, message) is     this.log = new File(log_filename)     this.message = message   method update(filename) is     log.write(replace('%s',filename,message)) class EmailAlertsListener is   private field email: string   constructor EmailAlertsListener(email, message) is     this.email = email     this.message = message   method update(filename) is     system.email(email, replace('%s',filename,message)) // Приложение может сконфигурировать издателей и подписчиков // как угодно, в зависимости от целей и конфигурации. class Application is   method config() is     editor = new TextEditor()     logger = new LoggingListener(       "/path/to/log.txt",       "Someone has opened file: %s");     editor.events.subscribe("open", logger)     emailAlers = new EmailAlertsListener(       "admin@example.com",       "Someone has changed the file: %s")     editor.events.subscribe("save", emailAlers)

Применимость

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

Эта задача может возникнуть при разработке GUI-фреймворка, когда надо дать возможность сторонним классам реагировать на клики по кнопкам.

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

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

Издатели ведут динамические списки. Все наблюдатели могут подписываться или отписываться на обновления прямо во время выполнения программы.

Шаги реализации

Разбейте вашу функциональность на две части: независимое ядро и опциональные зависимые части. Независимое ядро станет издателем. Зависимые части станут подписчиками.

Создайте интерфейс подписчиков. Обычно, в нём достаточно определить единственный метод оповещения.

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

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

Но если вы интегрируете паттерн в существующие классы, то создать новый базовый класс может быть затруднительно. В этом случае, вы можете поместить логику подписки во вспомогательный объект и делегировать ему работу из издателей.

Создайте классы конкретных издателей. Реализуйте их так, чтобы при каждом изменении состояния, они слали оповещения всем своим подписчикам.

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

Клиент должен создавать необходимое количество объектов подписчиков и подписывать их у издателей.

Преимущества и недостатки

Издатель не зависит от конкретных классов подписчиков.

Вы можете подписывать и отписывать получателей на лету.

Реализует принцип открытости/закрытости.

Наблюдатели оповещаются в случайном порядке.

Отношения с другими паттернами

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

Цепочка обязанностей передаёт запрос последовательно через цепочку потенциальных получателей, ожидая, что какой-то из них обработает запрос.

Команда устанавливает косвенную одностороннюю связь от отправителей к получателям.

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

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

Разница между Посредником и Наблюдателем не всегда очевидна. Чаще всего они выступают как конкуренты, но иногда могут работать вместе.

Цель Посредника — убрать обоюдные зависимости между компонентами системы. Вместо этого они становятся зависимыми от самого посредника. С другой стороны, цель Наблюдателя — обеспечить динамическую одностороннюю связь, в которой одни объекты косвенно зависят от других.

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

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

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

Состояние

Также известен как: State

Суть паттерна

Состояние — это поведенческий паттерн проектирования, который позволяет объектам менять поведение в зависимости от своего состояния. Извне создаётся впечатление, что изменился класс объекта.

Проблема

Паттерн Состояние невозможно рассматривать в отрыве от концепции машины состояний (также известной как стейт-машина или конечный автомат).

Конечный автомат.

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

Такой подход может быть применён и к отдельным объектам. Например, объект Документ может принимать три состояния: Черновик, Модерация или Опубликован. В каждом из них его метод опубликовать будет работать по-разному:

В первом случае, он отправит документ на модерацию.

Во втором — отправит документ в публикацию, но при условии, что это сделал администратор.

А в последнем — и вовсе ничего не будет делать.

Возможные состояния страницы и переходы между ними.

Машину состояний чаще всего реализуют с помощью множества условных операторов, if либо switch, которые проверяют текущее состояние объекта и выполняют соответствующее поведение. Наверняка вы уже реализовали хотя бы одну машину состояний в своей жизни, даже не зная об этом. Как на счёт вот такого кода, выглядит знакомо?

class Document   string state;   // ...   method publish() {     switch (state) {       "draft":         state = "moderation";         break;       "moderation":         if (currentUser.role == 'admin')           state = "published"         break;       "published":         // Do nothing.     }   }   // ...

Основная проблема машины состояний построенной таким образом проявится, если в Документ добавить ещё десяток состояний. Каждый метод будет состоять из увесистого условного оператора, перебирающего доступные состояния.

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

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

Решение

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

Вместо того чтобы хранить код всех состояний, первоначальный объект (называемый «контекстом») будет содержать ссылку на один из объектов-состояний и делегировать ему работу, зависящую от состояния.

Страница делегирует выполнение своему активному состоянию.

Благодаря тому, что состояния будут иметь общий интерфейс, контекст сможет делегировать работу состоянию, не привязываясь к его классу. Состояние и поведение контекста можно будет изменить в любой момент, подключив к нему другой объект-состояние.

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

Аналогия из жизни

Ваш смартфон ведёт себя по-разному, в зависимости от текущего состояния:

Когда телефон разблокирован, нажатие кнопок телефона приводит к каким-то действиям.

Когда телефон заблокирован, нажатие кнопок приводит к экрану разблокировки.

Когда телефон разряжен, нажатие кнопок приводит к экрану зарядки.

Структура

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

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

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

Состояние может иметь обратную ссылку на объект контекста. Через неё не только удобно получать из контекста нужную информацию, но и осуществлять смену его состояния.

И контекст, и объекты конкретных состояний могут решать, когда и какое следующее состояние будет выбрано. Чтобы переключить состояние, нужно подать другой объект-состояние в контекст.

Псевдокод

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

Пример изменение поведения проигрывателя с помощью состояний.

Объект проигрывателя содержит объект-состояние, которому и делегирует основную работу. Изменяя состояния, можно менять то, как ведут себя элементы управления проигрывателя.

// Общий интерфейс всех состояний. abstract class State is   protected field player: Player   // Контекст передаёт себя в конструктор состояния, чтобы   // состояние могло обращаться к его данным и методам в   // будущем, если потребуется.   constructor State(player) is     this.player = player   abstract method clickLock()   abstract method clickPlay()   abstract method clickNext()   abstract method clickPrevious() // Конкретные состояния реализуют методы абстрактного // состояния по-своему. class LockedState is   // При разблокировке проигрователя с заблокированными   // клавишами, он может принять одно из двух состояний.   method clickLock() is     if (player.playing)       player.changeState(new PlayingState(player))     else       player.changeState(new ReadyState(player))   method clickPlay() is     // Ничего не делать.   method clickNext() is     // Ничего не делать.   method clickPrevious() is     // Ничего не делать. // Они также могут переводить контекст в другие состояния. class ReadyState is   method clickLock() is     player.changeState(new LockedState(player))   method clickPlay() is     player.startPlayback()     player.changeState(new PlayingState(player))   method clickNext() is     player.nextSong()   method clickPrevious() is     player.previousSong() class PlayingState is   method clickLock() is     player.changeState(new LockedState(player))   method clickPlay() is     player.stopPlayback()     player.changeState(new ReadyState(player))   method clickNext() is     if (event.doubleclick)       player.nextSong()     else       player.fastForward(5)   method clickPrevious() is     if (event.doubleclick)       player.previous()     else       player.rewind(5) // Проигрыватель играет роль контекста. class Player is   field state: State   field UI, volume, playlist, currentSong   constructor Player() is     this.state = new ReadyState(this)     // Контекст заставляет состояние реагировать на     // пользовательский ввод вместо себя. Реакция может     // быть разной в зависимости от того, какое     // состояние сейчас активно.     UI = new UserInterface()     UI.lockButton.onClick(this.clickLock)     UI.playButton.onClick(this.clickPlay)     UI.nextButton.onClick(this.clickNext)     UI.prevButton.onClick(this.clickPrevious)   // Другие объекты должны иметь возможность заменить   // состояние проигрывателя.   method changeState(state: State) is     this.state = state   // Методы UI будут делегировать работу   // активному состоянию.   method clickLock() is     state.clickLock()   method clickPlay() is     state.clickPlay()   method clickNext() is     state.clickNext()   method clickPrevious() is     state.clickPrevious()   // Сервисные методы контекста, вызываемые состояниями.   method startPlayback() is     // ...   method stopPlayback() is     // ...   method nextSong() is     // ...   method previousSong() is     // ...   method fastForward(time) is     // ...   method rewind(time) is     // ...

Применимость

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

Паттерн предлагает выделить все поля и методы, связанные с определённым состоянием в собственные классы. Первоначальный объект будет постоянно ссылаться на один из объектов-состояний, делегируя ему большую часть работы. Для изменения состояния, в контекст достаточно будет подставляться другой объект-состояние.

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

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

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

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

Шаги реализации

Определитесь с классом, который будет играть роль контекста. Это может быть как существующий класс, в котором уже есть зависимость от состояния, так и новый класс, если код состояний размазан по нескольким классам.

Создайте интерфейс состояний. Он должен описывать методы, общие для всех состояний, обнаруженных в контексте. Заметьте, что не всё поведение контекста нужно переносить в состояние, а только то, которое зависит от состояний.

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

При переносе поведения из контекста, вы можете столкнуться с тем, что это поведение зависит от приватных полей или методов контекста, к кторым нет доступа из состояния. Есть парочка способов обойти эту проблему. Самый простой — оставить поведение внутри контекста, вызывая его из объекта состояния. С другой стороны, вы может сделать классы состояний вложенными в класс контекста, и тогда они получат доступ ко всем приватным частям контекста. Но последний способ доступен только в некоторых языках программирования (например, Java, C#).

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

Старые методы контекста, в которых находился зависимый от состояния код, замените на вызовы соответствующих методов объекта-состояния.

В зависимости от бизнес-логики, разместите код, который переключает состояние контекста либо внутри контекста, либо внутри классов конкретных состояний.

Преимущества и недостатки

Избавляет от множества больших условных операторов машины состояний.

Концентрирует в одном месте код, связанный с определённым состоянием.

Упрощает код контекста.

Может неоправданно усложнить код, если состояний мало и они редко меняются.

Отношения с другими паттернами

Мост, Стратегия и Состояние (а также слегка и Адаптер) имеют схожие структуры классов — все они построены на принципе «композиции», то есть делегирования работы другим объектам. Тем не менее, они отличаются тем, что решают разные проблемы. Помните, что паттерны — это не только рецепт построения кода определённым образом, но и описание проблем, которые привели к данному решению.

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

Стратегия

Также известен как: Strategy

Суть паттерна

Стратегия — это поведенческий паттерн проектирования, который определяет семейство схожих алгоритмов и помещает каждый из них в собственный класс. После чего, алгоритмы можно взаимозаменять прямо во время исполнения программы.

Проблема

Вы решили написать приложение-навигатор для путешественников. Он должен показывать красивую и удобную карту, позволяющую с лёгкостью ориентироваться в незнакомом городе.

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

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

Но и это ещё не всё. В ближайшей перспективе вы хотели бы добавить прокладку маршрутов по велодорожкам. А в отдалённом будущем — интересные маршруты посещения достопримечательностей.

Код навигатора становится слишком раздутым.

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

Любое изменение алгоритмов поиска, будь то исправление багов или добавление нового алгоритма, затрагивало основной класс. Это повышало риск сделать ошибку, случайно задев остальной работающий код.

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

Решение

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

Вместо того чтобы изначальный класс сам выполнял тот или иной алгоритм, он будет отыгрывать роль контекста, ссылаясь на одну из стратегий и делегируя ей выполнение работы. А для смены алгоритма будет достаточно подставить в контекст другой объект-стратегию.

Важно, чтобы все стратегии имели общий интерфейс. Используя этот интерфейс, контекст будет независимым от конкретных классов стратегий. С другой стороны, вы сможете изменять и добавлять новые виды алгоритмов, не трогая код контекста.

Стратегии постройки пути.

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

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

Класс навигатора будет иметь метод изменения стратегии, позволяющий изменять стратегию поиска пути на лету. Им сможет воспользоваться клиентский код навигатора, например, кнопки-переключатели типов маршрутов в пользовательском интерфейсе.

Аналогия из жизни

Различные стратегии попадания в аэропорт.

Вам нужно добраться до аэропорта. Можно доехать на автобусе, такси или велосипеде. Здесь вид транспорта является стратегией. Вы выбираете конкретную стратегию в зависимости от контекста (например, наличия денег или времени до отлёта).

Структура

Контекст хранит ссылку на объект конкретной стратегии, работая с ним объектом через общий интерфейс стратегий.

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

Для контекста не важно, какая именно вариация алгоритма будет выбрана, так как все они имеют одинаковый интерфейс.

Конкретные стратегии реализуют различные вариации алгоритма.

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

Обычно, клиент должен создать объект конкретной стратегии и передать его в контекст: либо через конструктор, либо в какой-то другой решающий момент, используя сеттер. Благодаря этому, контекст не знает о том, какая именно стратегия сейчас выбрана.

Псевдокод

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

// Общий интерфейс всех стратегий. interface Strategy is   method execute(a, b) // Каждая конкретная стратегия реализует общий интерфейс // своим способом. class ConcreteStrategyAdd implements Strategy is   method execute(a, b) is     return a + b class ConcreteStrategySubtract implements Strategy is   method execute(a, b) is     return a - b class ConcreteStrategyMultiply implements Strategy is   method execute(a, b) is     return a * b // Контекст всегда работает со стратегиями через общий // интерфейс. Он не знает какая именно стратегия ему подана. class Context is   private strategy: Strategy   method setStrategy(Strategy strategy) is     this.strategy = strategy   method executeStrategy(int a, int b) is     return strategy.execute(a, b) // Конкретная стратегия выбирается на более высоком уровне, // например, конфигуратором всего приложения. Готовый // объект-стратегия подаётся в клиентский объект, а затем // может быть заменён другой стратегией в любой момент // на лету. class ExampleApplication is   method main() is     Create context object.     Read first number.     Read last number.     Read the desired action from user input.     if (action == addition) then       context.setStrategy(new ConcreteStrategyAdd())     if (action == subtraction) then       context.setStrategy(new ConcreteStrategySubtract())     if (action == multiplication) then       context.setStrategy(new ConcreteStrategyMultiply())     result = context.executeStrategy(First number, Second number)     Print result.

Применимость

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

Стратегия позволяет варьировать поведение объекта во время выполнения программы, подставляя в него различные объекты-поведения (например, отличающиеся балансом скорости и потребления ресурсов).

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

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

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

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

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

Стратегия помещает каждую лапу такого оператора в отдельный класс-стратегию. Затем контекст получает определённый объект-стратегию от клиента и делегирует ему работу. Если вдруг понадобится сменить алгоритм, в контекст можно подать другую стратегию.

Шаги реализации

Определите алгоритм, который подвержен частым изменениям. Также подойдёт алгоритм, имеющий несколько вариаций, которые выбираются во время выполнения программы.

Создайте интерфейс стратегий, описывающий этот алгоритм. Он должен быть общим для всех вариантов алгоритма.

Поместите вариации алгоритма в собственные классы, которые реализуют этот интерфейс.

В классе контекста создайте поле для хранения ссылки на текущий объект-стратегию, а также метод для её изменения. Убедитесь в том, что контекст работает с этим объектом только через общий интерфейс стратегий.

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

Преимущества и недостатки

Горячая замена алгоритмов на лету.

Изолирует код и данные алгоритмов от остальных классов.

Уход от наследования к делегированию.

Реализует принцип открытости/закрытости.

Усложняет программу за счёт дополнительных классов.

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

Отношения с другими паттернами

Мост, Стратегия и Состояние (а также слегка и Адаптер) имеют схожие структуры классов — все они построены на принципе «композиции», то есть делегирования работы другим объектам. Тем не менее, они отличаются тем, что решают разные проблемы. Помните, что паттерны — это не только рецепт построения кода определённым образом, но и описание проблем, которые привели к данному решению.

Команда и Стратегия похожи по духу, но отличаются масштабом и применением:

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

С другой стороны, Стратегия описывает разные способы сделать одно и то же действие, позволяя взаимозаменять эти способы в каком-то объекте контекста.

Стратегия меняет поведение объекта «изнутри», а Декоратор изменяет его «снаружи».

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

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

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

Также известен как: Template Method

Суть паттерна

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

Проблема

Вы пишете программу для дата-майнинга в офисных документах. Пользователи будут загружать в неё документы в разных форматах (PDF, DOC, CSV), а программа должна извлекать из них полезную информацию.

В первой версии вы ограничились только обработкой DOC-файлов. В следующей версии, добавили поддержку CSV. А через месяц прикрутили работу с PDF-документами.

Классы дата майнинга содержат много дублирования.

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

К тому же остальной код, работающий с объектами этих классов, наполнен условиями, проверяющими тип обработчика перед началом работы. Весь этот код можно упростить, если слить все три класса воедино, либо свести их к общему интерфейсу.

Решение

Паттерн Шаблонный метод предлагает разбить алгоритм на последовательность шагов, описать шаги в отдельных методах и вызывать их в одном «шаблонном» методе друг за другом.

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

В нашем примере с дата-майнингом, мы можем создать общий базовый класс для всех трёх алгоритмов. Этот класс будет состоять из шаблонного метод, который последовательно вызывает шаги разбора документов.

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

Для начала, шаги шаблонного метода можно сделать абстрактными. Из-за этого все подклассы должны будут реализовать каждый из шагов по-своему. В нашем случае, все подклассы и так содержат реализацию каждого из шагов, поэтому ничего дополнительно делать не нужно.

По-настоящему важным является следующий этап. Теперь мы можем определить общее для всех трёх классов поведение и вынести его в суперкласс. В нашем примере, шаги открытия и закрытия документов будут отличаться для всех подклассов, поэтому останутся абстрактными. А вот одинаковый для всех типов документов код обработки данных переедет в базовый класс.

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

Но есть и третий тип шагов — хуки. Это «опциональные» шаги, которые выглядят как обычные методы, но не содержат никакого кода. Шаблонный метод останется рабочим, даже если ни один подкласс не переопределит такой хук. В то же время, хук даёт подклассам дополнительные точки «вклинивания» в ход шаблонного метода.

Аналогия из жизни

Проект типового дома могут немного изменить по желанию клиента.

Строители используют подход, похожий на шаблонный метод при строительстве типовых домов. У них есть основной архитектурный проект, в котором расписаны шаги строительства — заливка фундамента, постройка стен, постановка крыши, установка окон, обивка и так далее.

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

Структура

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

Конкретный класс переопределяет некоторые (или все) шаги алгоритма. Конкретные классы не переопределяют сам шаблонный метод.

Псевдокод

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

Пример классов искусственного интеллекта для простой игры.

Все расы игры будут содержать примерно такие же типы юнитов и строений, поэтому структура ИИ будет одинаковой. Но разные расы могут по-разному реализовать эти шаги. Так, например, орки будут агрессивней в атаке, люди — более активны в защите, а дикие монстры — вообще не будут заниматься строительством.

class GameAI is   // Шаблонный метод должен быть задан в базовом классе.   // Он состоит из вызовов методов в определённом порядке.   // Чаще всего эти методы являются шагами   // некоего алгоритма.   method turn() is     collectResources()     buildNewStructures()     buildUnits()     attack()   // Некоторые из этих методов могут быть реализованы   // прямо в базовом классе.   method collectResources() is     foreach (s in this.builtStructures) do       s.collect()   // А некоторые могут быть полностью абстрактными.   abstract method buildStructures()   abstract method buildUnits()   // Кстати, шаблонных методов в классе может   // быть несколько.   method attack() is     enemy = closestEnemy()     if (enemy == null)       sendScouts(map.center)     else       sendWarriors(enemy.position)   abstract method sendScouts(position)   abstract method sendWarriors(position) // Подклассы могут предоставлять свою реализацию шагов // алгоритма, не изменяя сам шаблонный метод. class OrcsAI extends GameAI is   method buildStructures() is     if (there are some resources) then       // Строить фермы, затем бараки, а потом цитадель.   method buildUnits() is     if (there are plenty of resources) then       if (there are no scouts)         // Построить раба и добавить в группу разведчиков.       else         // Построить пехотинца и добавить в группу воинов.   // ...   method sendScouts(position) is     if (scouts.length > 0) then       // Отправить разведчиков на позицию.   method sendWarriors(position) is     if (warriors.length > 5) then       // Отправить воинов на позицию. // Подклассы могут не только реализовывать абстрактные шаги, // но и переопределять шаги, уже реализованные в // базовом классе. class MonstersAI extends GameAI is   method collectResources() is     // Ничего не делать.   method buildStructures() is     // Ничего не делать.   method buildUnits() is     // Ничего не делать.

Применимость

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

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

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

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

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

Шаги реализации

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

Создайте абстрактный базовый класс. Определите в нём шаблонный метод. Этот метод должен состоять из вызовов шагов алгоритма. Имеет смысл сделать шаблонный метод финальным, чтобы подклассы не могли переопределить его (если ваш язык программирования это позволяет).

Добавьте в абстрактный класс методы для каждого из шагов алгоритма. Вы можете сделать эти методы абстрактными или добавить какую-то реализацию по умолчанию. В первом случае, все подклассы должны будут реализовать эти методы, а во втором — только если реализация шага в подклассе отличается от стандартной версии.

Подумайте о введении в алгоритм хуков. Чаще всего, хуки располагают между основными шагами алгоритма, а также до и после всех шагов.

Создайте конкретные классы, унаследовав их от абстрактного класса. Реализуйте в них все недостающие шаги и хуки.

Преимущества и недостатки

Облегчает повторное использование кода.

Вы жёстко ограничены скелетом существующего алгоритма.

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

С ростом количества шагов, шаблонный метод становится слишком сложно поддерживать.

Отношения с другими паттернами

Фабричный метод можно рассматривать как частный случай Шаблонного метода. Кроме того, Фабричный метод нередко бывает частью большого класса с Шаблонными методами.

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

Посетитель

Также известен как: Visitor

Суть паттерна

Посетитель — это поведенческий паттерн проектирования, который позволяет создавать новые операции, не меняя классы объектов, над которыми эти операции могут выполняться.

Проблема

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

Экспорт гео-узлов в XML.

Ваша задача — сделать экспорт этого графа в XML. Дело было бы плёвым, если бы вы могли редактировать классы узлов. В этом случае, можно было бы добавить метод экспорта в каждый тип узла, а затем, перебирая узлы географического графа, вызывать этот метод для каждого узла. Решение получилось бы изящным, так как полиморфизм позволил бы не привязываться к конкретным классам узлов.

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

Код XML-экспорта придётся добавить во все классы узлов, а это слишком накладно.

К тому же он сомневался в том, что экспорт в XML вообще уместен в рамках этих классов. Их основная задача была связана с геоданными, а экспорт выглядит как чужеродное поведение в рамках этих классов.

Была и ещё одна причина запрета. На следующей неделе мог понадобиться экспорт в какой-то другой формат данных, и вам снова пришлось бы трогать эти классы.

Решение

Паттерн Посетитель предлагает разместить новое поведение в отдельном классе, вместо того, чтобы множить его сразу в нескольких классах. Объекты, с которыми должно было быть связано поведение, не будут выполнять его самостоятельно. Вместо этого, вы будете передавать эти объекты в методы посетителя.

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

class ExportVisitor implements Visitor is   method doForCity(City c) { ... }   method doForIndustry(Industry f) { ... }   method doForSightSeeing(SightSeeing ss) { ... }   // ...

Здесь возникает вопрос, каким образом мы будет подавать узлы в объект посетитель. Так как все методы имеют отличающуюся сигнатуру, использовать полиморфизм при переборе узлов не получится. Придётся проверять тип узлов для того, чтобы выбрать соответствующий метод посетителя.

foreach (Node node : graph)   if (node instanceof City)     exportVisitor.doForCity((City) node);   if (node instanceof Industry)     exportVisitor.doForIndustry((Industry) node);   // ...

Тут не поможет даже механизм перегрузки методов (доступный в Java и C#). Если назвать все методы одинаково, то неопределённость реального типа узла всё равно не даст вызвать правильный метод. Механизм перегрузки всё время будет вызывать метод посетителя, соответствующий типу Node, а не реального класса поданного узла.

Но паттерн Посетитель решает и эту проблему, используя механизм двойной диспетчеризации. Вместо того чтобы самим искать нужный метод, мы можем поручить это объектам, которые передаём в параметрах посетителю. А они уже вызовут правильный метод посетителя.

// Client code foreach (Node node : graph)   node.accept(exportVisitor); // City class City is   method accept(Visitor v) is     v.doForCity(this);   // ... // Industry class Industry is   method accept(Visitor v) is     v.doForIndustry(this);   // ...

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

Аналогия из жизни

У страхового агента приготовлены полисы для разных видов организаций.

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

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

Придя в банк, он предлагает страховку от грабежа.

Придя на фабрику, он предлагает страховку предприятия от пожара и наводнения.

Структура

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

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

Компонент описывает метод принятия посетителя. Этот метод должен иметь единственный параметр, объявленный с типом интерфейса посетителя.

Конкретные компоненты реализуют методы принятия посетителя. Цель этого метода — вызвать тот метод посещения, который соответствует типу этого компонента. Так посетитель узнает, с каким именно компонентом он работает.

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

Псевдокод

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

Пример организации экспорта объектов в XML через отдельный класс-посетитель.

// Сложная иерархия компонентов. interface Shape is   method move(x, y)   method draw()   method accept(v: Visitor) // Метод принятия посетителя должен быть реализован в каждом // компоненте, а не только в базовом классе. Это поможет // программе определить какой метод посетителя нужно // вызвать, в случае если вы не знаете тип компонента. class Dot extends Shape is   // ...   method accept(v: Visitor) is     v.visitDot(this) class Circle extends Dot is   // ...   method accept(v: Visitor) is     v.visitCircle(this) class Rectangle extends Shape is   // ...   method accept(v: Visitor) is     v.visitRectangle(this) class CompoundShape implements Shape is   // ...   method accept(v: Visitor) is     v.visitCompoundShape(this) // Интерфейс посетителей должен содержать методы посещения // каждого компонента. Важно, чтобы иерархия компонентов // менялась редко, так как при добавлении нового компонента // придётся менять всех существующих посетителей. interface Visitor is   method visitDot(d: Dot)   method visitCircle(c: Circle)   method visitRectangle(r: Rectangle)   method visitCompoundShape(cs: CompoundShape) // Конкретный посетитель реализует одну операцию для всей // иерархии компонентов. Новая операция = новый посетитель. // Посетитель выгодно применять, когда новые компоненты // добавляются очень редко, а команды добавляются // очень часто. class XMLExportVisitor is   method visitDot(d: Dot) is     // Экспорт id и кординатов центра точки.   method visitCircle(c: Circle) is     // Экспорт id, кординатов центра и радиуса окружности.   method visitRectangle(r: Rectangle) is     // Экспорт id, кординатов левого-верхнего угла, ширины     // и высоты прямоугольника.   method visitCompoundShape(cs: CompoundShape) is     // Экспорт id составной фигуры, а также списка id     // подфигур, из которых она состоит. // Приложение может применять посетителя к любому набору // объектов компонентов, даже не уточняя их типы. Нужный // метод посетителя будет выбран благодаря проходу через // метод accept. class Application is   field allShapes: array of Shapes   method export() is     exportVisitor = new XMLExportVisitor()     foreach (shape in allShapes) do       shape.accept(exportVisitor)

Вам не кажется, что вызов метода accept – это лишнее звено здесь? Если так, то ещё раз рекомендую вам ознакомиться с проблемой раннего и позднего связывания в статье Посетитель и Double Dispatch.

Применимость

Когда вам нужно выполнить операцию над всеми элементами сложной структуры объектов (например, деревом).

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

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

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

Когда новое поведение имеет смысл только для некоторых классов из существующей иерархии.

Посетитель позволяет определить поведение только для этих классов и оставить его пустым для всех остальных.

Шаги реализации

Создайте интерфейс посетителя и объявите в нём методы «посещения» для каждого класса компонента, который существует в программе.

Опишите интерфейс компонентов. Если вы работаете с уже существующими классами, то объявите абстрактный метод принятия посетителей в базовом классе иерархии компонентов.

Реализуйте методы принятия во всех конкретных компонентах. Они должны переадресовывать вызовы тому методу посетителя, в котором класс параметра совпадает с текущим классом компонента.

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

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

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

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

Преимущества и недостатки

Упрощает добавление новых операций над всей связанной структурой объектов.

Объединяет родственные операции в одном классе.

Посетитель может накоплять состояние при обходе структуры компонентов.

Паттерн неоправдан, если иерархия компонентов часто меняется.

Может привести к нарушению инкапсуляции компонентов.

Отношения с другими паттернами

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

Вы можете выполнить какое-то действие над всем деревом Компоновщика при помощи Посетителя.

Посетитель можно использовать совместно с Итератором. Итератор будет отвечать за обход структуры данных, а Посетитель — за выполнение действий над каждым её компонентом.

Дополнительные материалы

Подробней о том, почему Посетитель нельзя заменить простой перегрузкой методов читайте в статье Посетитель и Double Dispatch.

Заключение

Поздравляю! Вы добрались до конца!

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

Вот парочка идей для следующих шагов, если вы ещё не определились что будете делать дальше:

Не забывайте, что вместе с этой книгой поставляется архив с реальными примерами кода на разных языках программирования.

Прочитайте книгу Джошуа Кериевски «Рефакторинг с использованием паттернов проектирования».

Не разбираетесь в рефакторинге? У меня есть хорошие материалы для вас.

Распечатайте шпаргалки по паттернам и повесьте их где-то на видном месте.

Оставьте отзыв об этой книге. Мне было бы очень интересно услышать ваше мнение, даже если это критика

#4007 Fueled by Johannes Gensfleisch zur Laden zum Gutenberg