Технологии программирования

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

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

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

— название и классификация паттерна (название паттерна должно четко отражать его назначение);

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

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

— мотивация (сценарий, иллюстрирующий задачу проектирования и то, как она решается данной структурой класса или объекта. Благодаря мотивации, можно лучше понять последующее, более абстрактное описание паттерна);

— применимость (описание ситуаций, в которых можно применять данный паттерн; примеры проектирования, которые можно улучшить с его помощью);

— структура (графическое представление классов в паттерне с использованием нотации, основанной на методике ОМТ, а также с использованием диаграмм взаимодействий для иллюстрации последовательностей запросов и отношений между объектами);

— участники (классы или объекты, задействованные в данном паттерне проектирования, и их функции);

— отношения (взаимодействие участников для выполнения своих функций);

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

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

— пример кода (фрагмент кода, иллюстрирующий вероятную реализацию на языках C++ или Smalltalk);

— известные применения (возможности применения паттерна в реальных системах; даются, по меньшей мере, два примера из различных областей);

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

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

1. Abstract Factory (абстрактная фабрика). Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

2. Adapter (адаптер). Преобразует интерфейс класса в некоторый другой интерфейс, ожидаемый клиентами. Обеспечивает совместную работу классов, которая была бы невозможна без данного паттерна из-за несовместимости интерфейсов.

3. Bridge (мост). Отделяет абстракцию от реализации, благодаря чему появляется возможность независимо изменять то и другое.

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

5. Chain of Responsibility (цепочка обязанностей). Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.

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