Конспект лекций, страница 21

Если получатель запроса – лист, то он иобрабатывает запрос. Если – составной объект, то он дополнительно рассылает запросысвоим частям.Результаты:• упрощается клиент, т. к. он единообразно работает с целым и частями;• облегчается добавление новых классов – они являются подклассами Leaf илиComposite;• трудно ограничить состав видов объектов в составе композиции того или иного вида.Рассмотрим пример (диаграмму объектов):aWindow : CompositeanOkButton : LeafaSubWindow : CompositeaCancelButton : LeafanYesButon : LeafaNoButton : LeafЕсли требуется запретить появление кнопок определенного вида в окнахопределенного вида, то эта задача целиком ложится на программиста, образецКомпоновщик нисколько не помогает её решить.Мост (Bridge)Классификация: структурный образец.Назначение: отделить абстракцию от реализации.Мотивация: наследование жестко привязывает реализацию к абстракции, поэтомулучше иметь иерархию наследования для интерфейсов и отдельно их реализации.Ситуации применимости:• обеспечение независимости абстракции и реализации;• необходимо расширять подклассами как интерфейсы, так и их реализации;• изменения в реализации не должны влиять на клиента;• необходимо разделить большую иерархию наследования на части.Участники:ClientConcreteImplementor1-theAbstraction1AbstractionabstractionOp()defaultMethod()-ImplementorRef1ImplementordefaultMethod()RefinedAbstraction6ConcreteImplementor2defaultMethod()••••Abstraction – абстракция, в которой определен интерфейс требуемый клиенту;RefinedAbstraction – уточненная абстракция с расширенным интерфейсом;Implementor – интерфейс для классов-реализаций;ConcreteImplementor – конкретный реализатор.Отношения:Абстракция перенаправляет запросы клиента одной из реализаций Implementora.Результаты:• реализация отделяется от интерфейса;• чтобы заменить реализацию нет необходимости перекомпилировать абстакцию и ееклиента;• система становится более легко модифицируемой.Фасад (Facade)Структурный паттерн, идея которого в том, чтобы предоставить унифицированныйинтерфейс к подсистеме (или пакету) в виде прокси-класса SubsystemProxy (в случаепакета – в виде фасада пакета).Пример:<<Interface>>IBillingSystem(from External System Interfaces)submitBill()StudentBillingTransactioncreate(forStudent : Student, forAmount : double)LocalvisibilityParametervisibility<<subsystem proxy>>BillingSystemsubmitBill(forStudent : Student, forTuition : double)<<entity>>Student.(from University Artifacts)1Field visibility0..1BillingSystemInterfacesubmit(theTransaction : StudentBillingTransaction)Используется для предоставления простого интерфейса к сложной подсистеме,явного определения точки входа в подсистему, сокращения связей клиентов подсистемы сее внутренними классами.Упрощает работу с подсистемой, ослабляет связность, скрывает внутреннееустройство подсистемы.В системе регистрации ВУЗа для подсистемы BillingSystem создается фасадBillingSystem, реализующий единственную операцию submitBill интерфейса подсистемыIBillingSystem.7Subsystem proxyфасадBilling SystemClient:BillingSystem:StudentBillingTransaction: Student.: BillingSystemInterface: Billing System1: submitBill(Student, double)2: create(Student, double)3: getName( )4: getAddress( )5: submit(StudentBillingTransaction)6: // open connection( )7: // process transaction( )8: // close connection( )Реализация операции заключается в формировании параметра для вызова методаBillingSystemInterface::submit(theTransaction) и собственно вызова этой операции.

По сути,фасад здесь является также Адаптером (вызов submitBill преобразуется в вызов submitграничного класса). Ситуация, когда совместно используются несколько образцов, частовстречается на практике.Proxy (Заместитель)Классификация: структурный образец.Назначение: для объекта создается суррогат, контролирующий доступ.Мотивация: есть «тяжелый» класс, объекты которого разумно создавать потребованию – эта обязанность возлагается на легкие суррогаты.Ситуации применимости:• удаленный заместитель (тяжелый объект невыгодно перемещать с узла на узел,поэтому на другом узле его представляет заместитель);• виртуальный заместитель;• защищающий заместитель (проверяет права доступа).Class_ClientProxy+ request()Subject+ request()RealClass+ request()8realClass->request()Участники:• Proxy – заместитель, хранящий ссылку на реальный объект;• Class_Client – клиентский класс;• Subject –общий интерфейс для класса и его заместителя;• RealClass – класс, для которого создается заместитель.Отношения:Заместитель получает запрос клиента и переадресует его реальному классу.

Детализависят от вида заместителя.: Class_Client: Proxy: RealClass1: request( )2: request( )Результаты (зависят от вида заместителя):• удаленный заместитель скрывает тот факт, что реальный объект находится на другомузле;• виртуальный заместитель оптимизирует приложение («тяжелые» объекты создаютсяпо требованию, пока в их создании нет необходимости, их представляют «легкие»объекты-заместители);• защищающий заместитель обеспечивает нужный режим доступа к объекту.Цепочка обязанностей (Chain of Responsibility)Классификация: образец поведения.Назначение: избежать привязки отправителя запроса к получателю, даваявозможность передать запрос через нескольких посредников.Ситуации применимости:• есть более одного объекта, способного обработать запрос, настоящий обработчикнеизвестен и должен быть найден автоматически (передадим по цепочке, пока ктонибудь не обработает);• адресат запроса не указан, но один из группы;Участники:Client-theHandler1•Handler1handleRequest()-successorConcreteHandler1ConcreteHandler2handleRequest()handleRequest()Handler – обобщенный обработчик, все специальные обработчики в цепочке являютсяего подклассами;9••ConcreteHandler – конкретный обработчик:o обрабатывает запрос;o знает следующего по цепочке;o если может обработать – обрабатывает иначе передает дальше.Client – отправляет запрос началу цепочки.КнопкаPrintОкноPrintОкноMainhandleHelphandleHelpshowHelpНапример, при вызове справки о кнопке Print кнопка не знает, кто долженпоказывать справку, поэтому она передает запрос по цепочке окну Print, оно, в своюочередь, главному окну, которое может обработать запрос.Результаты:• ослабляется связность (клиент связан лишь с началом цепочки);• гибкость в распределении обязанностей;• нет гарантий, что запрос будет обработан, может дойти до конца цепочки и пропасть.Iterator (Итератор)Классификация: образец поведения.Назначение: дать последовательный доступ к набору однородных объектов, нераскрывая его внутреннего представления.Ситуация применимости: есть структура данных, для которой нужно реализоватьодин или несколько способов обхода – каждый осуществляется отдельным итератором.Участники:• Iterator – общий интерфейс для доступа и обхода структуры данных;• ConcreteIterator –o конкретный способ обхода;o помнит позицию курсора (текущий элемент);• Aggregate – интерфейс для создания итератора;10•ConcreteAggregate – реализация интерфейса Aggregate.ConcreteIterator+ First()+ Next()+ IsDone()+ CurrentItem()ClientIterator+ First()+ Next()+ IsDone()+ CurrentItem()ConcreteAggregate+ CreateIterator()Aggregate+ CreateIterator()•••Результаты:поддерживаются разные способы обхода;упрощается интерфейс Aggregate;есть возможность иметь одновременно несколько активных обходов (столько, сколькообъектов-итераторов).Strategy (Стратегия)Классификация: образец поведения.Назначение: Определяет семейство алгоритмов, инкапсулирует каждый из них иделает их взаимозаменяемыми.Мотивация: есть несколько алгоритмов решения одной задачи,которыенежелательно «зашивать» в клиентский класс.Ситуации применимости:• Имеется много родственных классов, отличающихся только поведением.• Необходимо иметь несколько разных реализаций одной операции.• Нужно скрыть от клиента сложные, специфичные для алгоритма структуры данных.• Упрощение кода метода, представляющего собой длинное ветвление или switch.Участники:• Strategy – интерфейс общий для семейства алгоритмов;• ConcreteStrategy – конкретная стратегия, реализующая интерфейс;• Context – контекст, направляющий запросы клиента стратегиям;11-theContextClientContext1+ contextInterface()<<uses>><<Interface>>-StrategyRefStrategy1+ algorithmInterface()ConcreteStrategyAConcreteStrategyB+ algorithmInterface()+ algorithmInterface()•Client – клиентский класс.Результаты:• Иерархия классов стратегий определяет семейство алгоритмов или поведений,которые можно повторно использовать.• Инкапсуляция алгоритма в отдельный класс позволяет изменять его независимо отконтекста.• Избавляемся от if и switch (улучшаем читаемость кода).• Интерфейс класса Strategy общий для всех подклассов ConcreteStrategy – неважно,сложна или тривиальна их реализация.

Поэтому вполне вероятно, что некоторыестратегии не будут пользоваться всей передаваемой им информацией, особеннопростые.Приведем пример использования образца для реализации разных стратегий расчетаналогов:Decorator (Декоратор)Классификация: структурный образец.Назначение: добавление объекту новых обязанностей в динамике. Альтернативаподклассам.Мотивация: Например, хотим, чтобы библиотека GUI могла добавлять свойства(рамку) или новое поведение (прокрутку) к любому элементу GUI. Для этого«оборачиваем» элемент GUI в объект-декоратор.

Декоратор имеет тот же интерфейс. Он12переадресует запросы элементу, который в него «завернут».Ситуации применимости:• для динамического, прозрачного для клиентов добавления обязанностей объектам;• для реализации обязанностей, которые могут быть сняты с объекта;• когда расширение путем порождения подклассов по каким-то причинам неудобно илиневозможно.Участники:• Component – интерфейс для декорируемых объектов;• ConcreteComponent – класс декорируемых объектов;• Decorator – декоратор, ссылающийся на декорируемый объект и определяющийинтерфейс для декораторов, соответствующий интерфейсу Component;• ConcreteDecorator – реализует какое-либо дополнительное поведение;• Client – клиентский класс.<<Interface>>Результаты:-theComponent Component -componentRef• Позволяетгибко1добавлять объекту новые Client1 + defaultMethod()обязанности.