Шаблон проектирования

У этого термина существуют и другие значения, см. Паттерн.

Шаблон проектирования (паттерн, от англ. design pattern) — повторяемая архитектурная конструкция в сфере проектирования программного обеспечения, предлагающая решение проблемы проектирования в рамках некоторого часто возникающего контекста.

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

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

На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой архитектуру всей программной системы.

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

История

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

В 1987 году (Кент Бэк) (Kent Beck) и (Вард Каннингем) (Ward Cunningham) взяли идеи Александера и разработали шаблоны применительно к разработке программного обеспечения для разработки графических оболочек на языке Smalltalk.

В 1988 году (Эрих Гамма) (Erich Gamma) начал писать докторскую диссертацию при Цюрихском университете об общей переносимости этой методики на разработку программ.

В 1989—1991 годах Джеймс Коплин (James Coplien) трудился над разработкой идиом для программирования на и опубликовал в 1991 году книгу «Advanced C++ Idioms».

В этом же году Эрих Гамма заканчивает свою докторскую диссертацию и переезжает в США, где в сотрудничестве с Ричардом Хелмом (Richard Helm), Ральфом Джонсоном (Ralph Johnson) и (Джоном Влиссидесом) (John Vlissides) публикует книгу (Design Patterns — Elements of Reusable Object-Oriented Software). В этой книге описаны 23 шаблона проектирования. Также команда авторов этой книги известна общественности под названием «Банда четырёх» (англ. Gang of Four, часто сокращается до GoF). Именно эта книга стала причиной роста популярности шаблонов проектирования.

Плюсы

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

Минусы

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

Многие шаблоны проектирования в (объектно-ориентированном проектировании) можно рассматривать как идиоматическое воспроизведение элементов функциональных языков. (Питер Норвиг) утверждает, что 16 из 23 шаблонов, описанных в книге «(Банды четырёх)», в динамически-типизируемых языках реализуются существенно проще, чем в , либо оказываются незаметны. (Пол Грэхэм) считает саму идею шаблонов проектирования — антипаттерном, сигналом о том, что система не обладает достаточным уровнем (абстракции), и необходима её тщательная переработка. Нетрудно видеть, что само определение шаблона как «готового решения, но не прямого обращения к библиотеке» по сути означает отказ от повторного использования в пользу (дублирования). Это, очевидно, может быть неизбежным для сложных систем при использовании языков, не поддерживающих (комбинаторы) и (полиморфизм типов), и это в принципе может быть исключено в языках, обладающих свойством (гомоиконичности) (хотя и не обязательно эффективно), так как любой шаблон может быть реализован в виде исполнимого кода.

Типы шаблонов проектирования

Основные

Название	Оригинальное название	Описание	Описан в (Design Patterns)
Основные шаблоны (Fundamental)
(Шаблон делегирования)	Delegation pattern	Объект внешне выражает некоторое поведение, но в реальности передаёт ответственность за выполнение этого поведения связанному объекту.	н/д
(Шаблон функционального дизайна)	Functional design	Гарантирует, что каждый модуль компьютерной программы имеет только одну обязанность и исполняет её с минимумом побочных эффектов на другие части программы.	н/д
(Неизменяемый интерфейс)	Immutable interface	Создание (неизменяемого объекта).	н/д
(Интерфейс)	Interface	Общий метод для структурирования компьютерных программ для того, чтобы их было проще понять.	н/д
(Интерфейс-маркер)	Marker interface	В качестве атрибута (как пометки объектной сущности) применяется наличие или отсутствие реализации интерфейса-маркера. В современных языках программирования вместо этого могут применяться атрибуты или аннотации.	н/д
(Контейнер свойств)	Property container	Позволяет добавлять дополнительные свойства для класса в контейнер (внутри класса), вместо расширения класса новыми свойствами.	н/д
(Канал событий)	Event channel	Расширяет шаблон «издатель — подписчик», создавая централизованный канал для событий. Использует объект-представитель для подписки и объект-представитель для публикации события в канале. Представитель существует отдельно от реального издателя или подписчика. Подписчик может получать опубликованные события от более чем одного объекта, даже если он зарегистрирован только на одном канале.	н/д
(Порождающие шаблоны) (Creational) — шаблоны проектирования, которые абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Шаблон, порождающий классы, использует наследование, чтобы изменять инстанцируемый класс, а шаблон, порождающий объекты, делегирует инстанцирование другому объекту.
(Абстрактная фабрика)	Abstract factory	Класс, который представляет собой интерфейс для создания компонентов системы.	Да
(Строитель)	Builder	Класс, который представляет собой интерфейс для создания сложного объекта.	Да
(Фабричный метод)	Factory method	Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать.	Да
(Отложенная инициализация)	Lazy initialization	Объект, инициализируемый во время первого обращения к нему.	Нет
(Мультитон)	Multiton	Гарантирует, что класс имеет поименованные экземпляры объекта и обеспечивает глобальную точку доступа к ним.	Нет
(Объектный пул)	Object pool	Класс, который представляет собой интерфейс для работы с набором инициализированных и готовых к использованию объектов.	Нет
Прототип	Prototype	Определяет интерфейс создания объекта через клонирование другого объекта вместо создания через конструктор.	Да
(Получение ресурса есть инициализация)	Resource acquisition is initialization (RAII)	Получение некоторого ресурса совмещается с инициализацией, а освобождение — с уничтожением объекта.	Нет
(Одиночка)	Singleton	Класс, который может иметь только один экземпляр.	Да
Структурные шаблоны (Structural) определяют различные сложные структуры, которые изменяют (интерфейс) уже существующих объектов или его реализацию, позволяя облегчить разработку и оптимизировать программу.
(Адаптер)	Adapter / Wrapper	Объект, обеспечивающий взаимодействие двух других объектов, один из которых использует, а другой предоставляет несовместимый с первым интерфейс.	Да
(Мост)	Bridge	Структура, позволяющая изменять интерфейс обращения и интерфейс реализации класса независимо.	Да
(Компоновщик)	Composite	Объект, который объединяет в себе объекты, подобные ему самому.	Да
(Декоратор) или Wrapper/Обёртка	Decorator	Класс, расширяющий функциональность другого класса без использования наследования.	Да
(Фасад)	Facade	Объект, который абстрагирует работу с несколькими классами, объединяя их в единое целое.	Да
(Единая точка входа)	Front controller	Обеспечивает унифицированный интерфейс для интерфейсов в подсистеме. Front Controller определяет высокоуровневый интерфейс, упрощающий использование подсистемы.	Нет
(Приспособленец)	Flyweight	Это объект, представляющий себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым.	Да
(Заместитель)	Proxy	Объект, который является посредником между двумя другими объектами, и который реализует/ограничивает доступ к объекту, к которому обращаются через него.	Да
Поведенческие шаблоны (Behavioral) определяют взаимодействие между объектами, увеличивая таким образом его гибкость.
(Цепочка обязанностей)	Chain of responsibility	Предназначен для организации в системе уровней ответственности.	Да
(Команда), Action, Transaction	Command	Представляет действие. Объект команды заключает в себе само действие и его параметры.	Да
(Интерпретатор)	Interpreter	Решает часто встречающуюся, но подверженную изменениям, задачу.	Да
(Итератор), (Cursor)	Iterator	Представляет собой объект, позволяющий получить последовательный доступ к элементам объекта-агрегата без использования описаний каждого из объектов, входящих в состав агрегации.	Да
(Посредник)	Mediator	Обеспечивает взаимодействие множества объектов, формируя при этом слабую связанность и избавляя объекты от необходимости явно ссылаться друг на друга.	Да
(Хранитель)	Memento	Позволяет не нарушая (инкапсуляцию) зафиксировать и сохранить внутренние состояния объекта так, чтобы позднее восстановить его в этих состояниях.	Да
(Null Object)	Null Object	Предотвращает нулевые указатели, предоставляя объект «по умолчанию».	Нет
(Наблюдатель) или Издатель — подписчик	Observer	Определяет зависимость типа «один ко многим» между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом событии.	Да
^[англ.]	Servant	Используется для обеспечения общей функциональности группе классов.	Нет
(Спецификация)	Specification	Служит для связывания бизнес-логики.	Нет
(Состояние)	State	Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния.	Да
(Стратегия)	Strategy	Предназначен для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости.	Да
(Шаблонный метод)	Template method	Определяет основу алгоритма и позволяет наследникам переопределять некоторые шаги алгоритма, не изменяя его структуру в целом.	Да
(Посетитель)	Visitor	Описывает операцию, которая выполняется над объектами других классов. При изменении класса Visitor нет необходимости изменять обслуживаемые классы.	Да
	Simple Policy		Нет
	Event listener		Нет
^[англ.]	Single-serving visitor	Оптимизирует реализацию шаблона посетитель, который инициализируется, единожды используется, и затем удаляется.	Нет
^[англ.]	Hierarchical visitor	Предоставляет способ обхода всех вершин иерархической структуры данных (напр. древовидной).	Нет

Частные

Шаблоны параллельного программирования

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

Название	Оригинальное название	Описание
(Активный объект)	Active object	Служит для отделения потока выполнения метода от потока, в котором он был вызван. Использует шаблоны асинхронный вызов методов и планировщик.
^[англ.]	Balking	Служит для выполнения действия над объектом только тогда, когда тот находится в корректном состоянии.
^[англ.]	Binding properties	Комбинирует несколько наблюдателей для обеспечения синхронизации свойств в различных объектах.
^[англ.]	Messaging pattern, Messaging design pattern (MDP)	Позволяет компонентам и приложениям обмениваться информацией (сообщениями).
(Блокировка с двойной проверкой)	Double checked locking	Предназначен для уменьшения накладных расходов, связанных с получением блокировки.
^[англ.]	Event-Based Asynchronous	Адресные проблемы с Асинхронным паттерном, которые возникают в программах с несколькими потоками.
^[англ.]	Guarded suspension	Используется для блокировки выполнения действия над объектом только тогда, когда тот находится в корректном состоянии.
(Блокировка)	Lock	Один поток блокирует ресурс для предотвращения доступа или изменения его другими потоками.
(Монитор)	Monitor	Объект, предназначенный для безопасного использования более чем одним потоком.
(Реактор)	Reactor	Предназначен для синхронной передачи запросов сервису от одного или нескольких источников.
(Блокировка чтения-записи)^[англ.]	Read/write lock	Позволяет нескольким потокам одновременно считывать информацию из общего хранилища, но позволяя только одному потоку в текущий момент времени её изменять.
(Планировщик)	Scheduler	Обеспечивает механизм реализации политики планирования, но при этом не зависящих ни от одной конкретной политики.
^[англ.]		Предоставляет пул потоков для обработки заданий, представленных обычно в виде очереди.
^[англ.]		Служит для предоставления различных глобальных переменных для разных потоков.
(Однопоточное выполнение)	Single thread execution	Препятствует конкурентному вызову метода, тем самым запрещая параллельное выполнение этого метода.
	Cooperative pattern	Обеспечивает механизм безопасной остановки потоков исполнения, используя общий флаг для сигнализирования прекращения работы потоков.

Шаблоны генерации объектов

• (Singleton)
• (Factory Method)
• (Abstract Factory)
• Prototype

Шаблоны программирования гибких объектов

• (Composite)
• (Decorator)
• (Facade)

Шаблоны выполнения задач

• (Interpreter)
• (Strategy)
• (Observer)
• (Visitor)
• (Command)

Шаблоны архитектуры системы

Основная статья:

• Model-View-Controller (MVC) Модель-представление-контроллер.
• (Model-View-Presenter).
• (Model-View-ViewModel).
• ^[англ.].
• (Naked objects).
• (Hierarchical Model-View-Controller).
• (VIPER).

Enterprise

• (Active Record) — способ доступа к данным реляционных баз данных в объектно-ориентированном программировании.
• .
• .
• .
• (DAO) (Data Access Object) Объект Доступа к Данным.
• .
• .
• .
• .
• .
• (Service Locator/Локатор Служб).
• .
• .
• .
• .
• .
• .
• .

Шаблоны проектирования потоковой обработки

Шаблоны проектирования распределённых систем

Шаблоны Баз Данных

• Data Mapper
• Identity Map
• Unit of Work
• Lazy Load

Прочие

• .

Другие типы шаблонов

Также на сегодняшний день существует ряд других шаблонов.

• описывают предоставление доступа к хранимой информации.
• описывают основной подход для составления требований для программного обеспечения (requirement analysis) до начала самого процесса программной разработки.
• описывают процесс общения между отдельными участниками/сотрудниками организации.
• описывают организационную иерархию предприятия/фирмы
• Антипаттерны (Anti-Design-Patterns) описывают, как не следует поступать при разработке программ, показывая характерные ошибки в дизайне и в реализации.

См. также

• Антипаттерн
• (Дизайн-манифест)
• (Обобщённое программирование)
• (Шаблоны J2EE)
• (CQRS)
• (Dependency Injection)
• (Книга «Design Patterns» (от создателей шаблонов проектирования))
• (GRASP)
• UML

Примечания

1. Макконнелл, 2005, с. 100—101.
2. Макконнелл, 2005, с. 101.
3. Design Patterns in Haskell  (неопр.). Дата обращения: 5 декабря 2014. 13 декабря 2014 года.
4. Peter Norvig — Design Patterns in Dynamic Languages (slides)  (неопр.). Дата обращения: 5 декабря 2014. 12 декабря 2014 года.
5. Revenge of the Nerds  (неопр.). — «In the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.» Дата обращения: 13 февраля 2015. 7 июня 2019 года.
6. Абельсон, Сассман. (Структура и интерпретация компьютерных программ) (SICP).. цитаты: «Можно строить абстракции процедур и данных, можно использовать функции высших порядков, чтобы охватить общие шаблоны их использования, … и можно с легкостью реализовывать встроенные языки.» (с.16); «Одна из тех вещей, которых мы должны требовать от мощного языка программирования — это возможность строить абстракции путём присвоения имен общим схемам, а затем прямо работать с этими абстракциями. … Часто одна и та же схема программы используется с различными процедурами. Для того чтобы выразить эти схемы как понятия, нам нужно строить процедуры, которые принимают другие процедуры как аргументы либо возвращают их как значения.» (с.70); «определение шаблонных схем в виде процедур служит средством абстракции.» (с.263); глава 4.1.5 «Данные как программы» (с.357-360); понятие о «средствах абстракции» и их роли дано на с.25.
7. Binding Properties  (неопр.). Дата обращения: 10 марта 2011. 11 апреля 2012 года.
8. Christian Nagel, Bill Evjen, Jay Glynn, Karli Watson, and Morgan Skinner. Event-based Asynchronous Pattern // Professional C# 2008 (неопр.). — Wiley, 2008. — С. 570—571. — .
9. Lock Pattern  (неопр.). Дата обращения: 10 марта 2011. 23 октября 2012 года.
10. Interview and Book Excerpt: Dan Haywood’s Domain-Driven Design Using Naked Objects  (неопр.). Дата обращения: 10 июля 2015. 3 марта 2021 года.

Литература

• Zandstra M. PHP Objects, Patterns, and Practice. — 5th Edition. — «», 2016. — С. 583. — .
• Зандстра М. PHP. Объекты, шаблоны и методики программирования. — 5-е изд.. — СПб.: «», 2019. — С. 736. — .
• Фаулер, Мартин. Рефакторинг кода на JavaScript: улучшение проекта существующего кода. — 2-е изд.. — СПб.: «», 2019. — С. 464. — .
• Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования = PHP Objects, Patterns and Practice, Third Edition. — 3-е издание. — М.: «», 2015. — С. 368. — .
• Джейсон Мак-Колм Смит. Элементарные шаблоны проектирования = Elemental Design Patterns. — М.: «», 2012. — 304 с. — .
• Фаулер, Мартин, Бек, Кент, Брант, Джон, Опдайк, Уильям, Робертс, Дон. Рефакторинг: улучшение проекта существующего кода. — М.: «», 2019. — 448 с. — .
• Мартин Фаулер. Шаблоны корпоративных приложений (Signature Series) = Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series). — М.: «», 2012. — 544 с. — .
• Марк Гранд. Шаблоны проектирования в JAVA. Каталог популярных шаблонов проектирования, проиллюстрированных при помощи UML = Patterns in Java, Volume 1. A Catalog of Reusable Design Patterns Illustrated with UML. — М.: «», 2004. — С. 560. — .
• Крэг Ларман. Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development. — М.: «», 2006. — С. 736. — .
• Стив Макконнелл. Совершенный код = Code complete. — СПб.: Питер, 2005. — С. 896. — (Мастер-класс). — , 5-469-00822-3.

Ссылки

• Ольга Дубина.   (неопр.). — Обзор нескольких наиболее значительных монографий, посвященных паттернам проектирования информационных систем. Дата обращения: 5 сентября 2006. Архивировано из оригинала 27 августа 2006 года.
• Portland Pattern Repository — список шаблонов проектирования на движке вики
• Eclipse’s Culture of Shipping (англ.) (Erich Gamma)