Лекция 10. Образцы проектирования

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

Основные составляющие части образца:

Имя. Идентифицирует образец, Хорошее имя характеризует решаемую проблему и способ ее решения.

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

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

Результаты. Следствия применения паттерна и компромиссы. Преимущества и недостатки образца. Влияние использования образца на гибкость, расширяемость и переносимость системы.

Полное описание образца в сборнике Гаммы и др. («банды четырех») включает:

• Название.

• Назначение (краткое описание функций образца и решаемой задачи).

• Другие известные названия.

• Мотивация (иллюстрация решаемой задачи проектирования).

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

• Структура (диаграмма классов).

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

• Отношения (диаграмма взаимодействия экземпляров классов-участников).

• Результаты.

• Реализация (сложности, подводные камни при реализации образца, рекомендации, зависимость от языка программирования).

• Пример кода.

• Известные применения (2 или более применений в различных областях).

• Родственные паттерны (связь с другими образцами, различия, использование образца в сочетании с другими).

Классификация образцов:

• Порождающие образцы (способы создания экземпляров классов).

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

• Образцы поведения (способы организации взаимодействий).

Рассмотрим несколько образцов.

Абстрактная фабрика (Abstract Factory)

Классификация: образец порождения объектов.

Назначение: предоставляет интерфейс для создания взаимосвязанных и взаимозависимых объектов, не определяя их конкретных классов.

Мотивация: часто встает задача проектирования программной системы независимой от конкретной реализации GUI.

Ситуации применимости:

• Система не должна зависеть от того как создаются, компонуются и представляются входящие в нее объекты;

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

• Система должна конфигурироваться одним из семейств составляющих ее объектов;

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

Участники:

• AbstractFactory – интерфейс с операциями для порождения экземпляров абстрактных классов-продуктов.

• ConcreteFactory – реализация порождения экземпляров конкретных классов.

• AbstractProduct – интерфейс с операциями класса-продукта.

• ConcreteProduct – реализация абстрактного продукта, объекты которой порождаются одной из конкретных фабрик.

• Client – класс пользующийся интерфейсами AbstractFactory и AbstractProduct.

Отношения:

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

Результаты:

• изоляция клиента от деталей реализации классов-продуктов (их имена известны только конкретной фабрике);

• упрощение замены семейств продуктов;

• набор продуктов фиксирован, добавлять новые трудно.

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

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

Фабричный метод (Factory method)

Классификация: образец порождения объектов.

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

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

Ситуации применимости:

• Класс заранее не знает, объекты каких классов нужно создавать;

• Известно лишь, что это будет экземпляр одного из подклассов (реализации) какого-то абстрактного класса (интерфейса);

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

Участники:

• Product – интерфейс порождаемых объектов;

• ConcreteProduct – конкретные реализации продукта;

• Creator – интерфейс порождения экземпляров продукта, в котором определен фабричный метод (factoryMethod), может определять реализацию фабричного метода по умолчанию;

• ConcreteCreator – реализация создателя для порождения конкретного продукта.

Отношения: Creator полагается на свои подклассы в определении factoryMethod’а, возвращающего экземпляр конкретного продукта.

Результаты:

• нет необходимости встраивать в код зависящие от приложения классы;

• код связан лишь с интерфейсом класса Product, поэтому может работать с любым конкретным продуктом;

• накладные расходы: при создании даже одного экземпляра конкретного продукта понадобится создать экземпляр ConcreteCreator.

Адаптер (Adapter)

Классификация: структурный образец.

Назначение: преобразует один интерфейс в другой, обеспечивая совместимость.

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

Ситуация применимости: обеспечение совместимости существующего класса при его повторном использовании.

Участники:

• Target – требуемый клиентом интерфейс;

• Client – клиент;

• Adaptee – адаптируемый класс или интерфейс;

• Adapter – класс-адаптер, в методе request вызывается specificRequest из Adaaptee.

Отношения:

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

Результаты:

• паттерн не работает, если надо адаптировать не только класс, но и его подклассы;

• вводится только один дополнительный объект.

Composite (Компоновщик)

Классификация: структурный образец.

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

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

Ситуации применимости:

• нужно представить иерархию объектов «часть-целое»;

• нужно дать одинаковый интерфейс к составным и простым объектам.

Участники:

• Component – компонент, определяющий единый интерфейс, содержащий реализации общих операций по умолчанию;

• Leaf – простые (элементарные) объекты;

• Composite – составной объект;

• Client – работает с объектами через интерфейс, объявленный в компоненте.

Отношения:

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

Результаты:

• упрощается клиент, т. к. он единообразно работает с целым и частями;

• облегчается добавление новых классов – они являются подклассами Leaf или Composite;

• трудно ограничить состав видов объектов в составе композиции того или иного вида.

Мост (Bridge)

Классификация: структурный образец.

Назначение: отделить абстракцию от реализации.

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

Ситуации применимости:

• обеспечение независимости абстракции и реализации;

• необходимо расширять подклассами как интерфейсы, так и их реализации;

• изменения в реализации не должны влиять на клиента;

• необходимо разделить большую иерархию наследования на части.

Участники:

• Abstraction – абстракция, в которой определен интерфейс требуемый клиенту;

• RefinedAbstraction – уточненная абстракция с расширенным интерфейсом;

• Implementor – интерфейс для классов-реализаций;

• ConcreteImplementor – конкретный реализатор.

Отношения:

Абстракция перенаправляет запросы клиента одной из реализаций Implementora.

Результаты:

• реализация отделяется от интерфейса;

• чтобы заменить реализацию нет необходимости перекомпилировать абстакцию и ее клиента;

• система становится более легко модифицируемой.

Фасад (Facade)

Структурный паттерн, идея которого в том, чтобы предоставить унифицированный интерфейс к подсистеме (или пакету) в виде прокси-класса SubsystemProxy (в случае пакета – в виде фасада пакета).

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

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

Proxy (Заместитель)

Классификация: структурный образец.

Назначение: для объекта создается суррогат, контролирующий доступ.

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

Ситуации применимости:

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

• виртуальный заместитель;

• защищающий заместитель (проверяет права доступа).

Участники:

• Proxy – заместитель, хранящий ссылку на реальный объект;

• Class_Client – клиентский класс;

• Subject –общий интерфейс для класса и его заместителя;

• RealClass – класс, для которого создается заместитель.

Отношения:

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

Результаты (зависят от вида заместителя):

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

• виртуальный заместитель оптимизирует приложение («тяжелые» объекты создаются по требованию, пока в их создании нет необходимости, их представляют «легкие» объекты-заместители);

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

Цепочка обязанностей (Chain of Responsibility)

Классификация: образец поведения.

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

Ситуации применимости:

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

• адресат запроса не указан, но один из группы;

Участники:

• Handler – обобщенный обработчик, все специальные обработчики в цепочке являются его подклассами;

• ConcreteHandler – конкретный обработчик:

  • обрабатывает запрос;

  • знает следующего по цепочке;

  • если может обработать – обрабатывает, иначе передает дальше.

• Client – отправляет запрос началу цепочки.

Результаты:

• ослабляется связность (клиент связан лишь с началом цепочки);

• гибкость в распределении обязанностей;

• нет гарантий, что запрос будет обработан, может дойти до конца цепочки и пропасть.

Iterator (Итератор)