CodeLAB
на главную карта сайта обратная связь

Популярные задачи:

#Использование компилируемых (prepared) запросов. (31864 hits)
#Сортировка выбором, общий подход. (74521 hits)
#сортировка пузырьком. (154950 hits)
#Рисование линии (по Брезенхэму). (34938 hits)
#Случайный выбор нескольких несовпадающих значений из множества. (60302 hits)
#Разбор строки. (274557 hits)
#Работа с камерой. (36793 hits)
#Сортировка Шелла, оптимальный выбор приращений. (197893 hits)
#Рисование окружности (по Брезенхэму). (34902 hits)
#Динамическая очистка выпадающего списка (select) на javascript. (92859 hits)
#Как работать с zip архивами стандартными средствами windows. (43251 hits)
#Простой генератор случайных чисел. (135845 hits)
#Как посчитать одинаковые пары за 1 проход (самая быстрая версия!). (3372 hits)
#Циклический сдвиг массива или строки - 3 уникальных алгоритма. (396141 hits)
#Поразрядная сортировка массива подсчетом. (134883 hits)
#Пирамидальная сортировка. (208253 hits)
#Шейкер-сортировка. (72853 hits)
#Рисование тора. (36105 hits)
#Логирование в GUI. (33401 hits)
#Код. (182913 hits)


Главная >> Каталог задач >> Паттерны >> Структурные >> Адаптер (Adapter)

Адаптер (Adapter)

Aвтор:
Дата:
Просмотров: 146139
реализации(java: 4шт...) +добавить

Имя

«Паттерн
Adapter (или Wrapper)»
Адаптер – паттерн, унифицирующий классы и объекты.

Условия, Задача, Назначение

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

Мотивация

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

Рассмотрим, например, графический редактор, благодаря которому пользователи могут рисовать на экране графические элементы (линии, многоугольники, текст и т.д.) и организовывать их в виде картинок и диаграмм. Основной абстракцией графического редактора является графический элемент, который имеет изменяемую форму и изображает сам себя. Интерфейс графических элементов определен абстрактным классом Shape. Редактор определяет подкласс класса Shape для каждого вида графических объектов: LineShape для прямых, PolygonShape для многоугольников и т.д.
Классы для элементарных геометрических фигур, например LineShape и PolygonShape, реализовать сравнительно просто, поскольку заложенные в них возможности рисования и редактирования крайне ограничены. Но подкласс TextShape, умеющий отображать и редактировать текст, уже значительно сложнее, поскольку даже для простейших операций редактирования текста нужно нетривиальным образом обновлять экран и управлять буферами. В то же время, возможно, существует уже готовая библиотека для разработки пользовательских интерфейсов, которая предоставляет развитый класс TextView, позволяющий отображать и редактировать текст. В идеале мы хотели бы повторно использовать TextView для реализации TextShape, но библиотека  разрабатывалась без учета классов Shape, поэтому заставить объекты TextView и Shape работать совместно не удается.
Так каким же образом существующие и независимо разработанные классы вроде TextView могут работать в приложении, которое спроектировано под другой,  несовместимый интерфейс? Можно было бы так изменить интерфейс класса TextView, чтобы он соответствовал интерфейсу Shape, только для этого нужен исходный код. Но даже если он доступен, то вряд ли разумно изменять TextView: библиотека не должна приспосабливаться к интерфейсам каждого конкретного приложения.
Вместо этого мы могли бы определить класс TextShape так, что он будет
адаптировать интерфейс класса TextView к интерфейсу Shape. Это допустимо сделать
двумя способами:
  1. Реализуя интерфейс Shape, и наследуясь от Text View
  2. Включив экземпляр TextView в TextShape и реализовав TextShape (т.е. рализовав интерфейс Shape) используя интерфейс класса TextView, т.е. попросту пользуясь классом TextView.

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

На этой диаграмме показан адаптер объекта. Видно, как запрос BoundingBox, объявленный в классе Shape, преобразуется в запрос GetExtent, определенный в классе TextView. Поскольку класс TextShape адаптирует TextView к интерфейсу Shape, графический редактор может воспользоваться классом TextView, хотя тот и имеет несовместимый интерфейс.
Часто адаптер отвечает за функциональность, которую не может предоставить адаптируемый класс. На диаграмме показано, как адаптер выполняет такого рода функции. У пользователя должна быть возможность перемещать любой объект класса Shape в другое место, но в классе TextView такая операция не предусмотрена. TextShape может добавить недостающую функциональность, самостоятельно реализовав операцию CreateManipulator класса Shape, которая возвращает экземпляр подходящего подкласса Manipulator.
Manipulator - это абстрактный класс объектов, которым известно, как анимировать Shape в ответ на такие действия пользователя, как перетаскивание фигуры в другое место. У класса Manipulator имеются подклассы для различных фигур. Например, TextManipulator - подкласс для TextShape. Возвращая экземпляр TextManipulator, объект класса TextShape добавляет новую функциональность, которой в классе TextView нет, а классу Shape требуется.

Признаки применения, использования паттерна Адаптер (Adapter)

Если:
  1. Хотите использовать существующий класс, но его интерфейс не соответствует вашим потребностям
  2. Собираетесь создать повторно используемый класс, который должен взаимодействовать с заранее неизвестными или не связанными с ним классами, имеющими несовместимые интерфейсы
  3. (Только для адаптера объектов!) Нужно объединить интерфейсы нескольких классов, причем в наличии могут быть уже только объекты-подклассы каждого из этих классов, а не экземпляры самих этих классов. В этом случае адаптер объектов может приспосабливать интерфейс их общего родительского класса.

Решение

Адаптер класса реализуется через множественное наследование. Этим достигается адаптация одного интерфейса к другому.

Адаптер объекта применяет композицию объектов.

Участники паттерна Адаптер (Adapter)

  1. Target (Shape) – целевой интерфейс.
    Определяет зависящий от предметной области интерфейс, которым пользуется Client.
  2. Client (DrawingEditor) – клиент.
    Взаимодействует с объектами, удовлетворяющими интерфейсу Target.
  3. Adaptee (TextView) – адаптируемый интерфейс.
    Определяет существующий интерфейс класса (библиотеки), который нуждается в адаптации.
  4. Adapter (Text Shape) – адаптер.
    Класс, адаптирующий интерфейс Adaptee к интерфейсу Target.

Схема использования паттерна Адаптер (Adapter)

Клиенты (Client) вызывают операции экземпляра адаптера Adapter. В свою очередь

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

Вопросы, касающиеся реализации паттерна Адаптер (Adapter)

Ниже приведены вопросы, которые следует рассмотреть, когда вы решаете
применить паттерн адаптер:
  1. Объем работы по адаптации.
    Адаптеры сильно отличаются по тому объему работы, который необходим для адаптации интерфейса Adaptее к интерфейсу Target. Это может быть как простейшее преобразование, например, изменение имен операций, так и поддержка совершенно другого набора операций. Объем работы зависит от того, насколько сильно отличаются друг от друга интерфейсы целевого и адаптируемого классов;
  2. Сменные адаптеры.
    Степень повторной используемости класса тем выше, чем меньше предположений делается о тех классах, которые будут его применять. Реализуя адаптацию интерфейса Adaptee через дополнительный класс (Adapter), вы отказываетесь от предположения, что другим классам станет доступен тот же самый интерфейс Adaptee. Другими словами, адаптация интерфейса позволяет включить ваш класс(Adaptee) в существующие системы(Client), которые спроектированы для класса с другим интерфейсом(Target). Помимо этого, существует специальное понятие сменный адаптер (pluggable adapter), обозначающее классы со встроенной адаптацией интерфейса.
    Рассмотрим виджет TreeDisplay, позволяющий графически отображать древовидные структуры. Если бы это был специализированный виджет, предназначенный только для одного приложения, то мы могли бы потребовать специального интерфейса от объектов, которые он отображает. Но если мы хотим сделать его повторно используемым (например, частью библиотеки полезных виджетов), то предъявлять такое требование неразумно. Разные приложения, скорей всего, будут определять собственные классы для представления древовидных структур, и не следует заставлять их пользоваться именно нашим интерфейсом абстрактного класса Tree. А у разных структур деревьев будут и разные интерфейсы.
    Например, в иерархии каталогов добраться до потомков удастся с помощью операции GetSubdirectories, тогда как для другой иерархии наследования соответствующая операция может называться GetSubclasses или GetInnerElements например. Повторно используемый виджет TreeDisplay должен «уметь» отображать иерархии обоих видов, даже если у них разные интерфейсы. Другими словами, в TreeDisplay должна быть встроена возможность адаптации интерфейсов. О способах встраивания адаптации интерфейсов в классы будет сказано ниже.
  3. Использование двусторонних адаптеров для обеспечения прозрачности.
    Адаптеры объектов непрозрачны для всех клиентов. Адаптированный объект уже не обладает интерфейсом Adaptее, так что его нельзя использовать там, где Adaptee был применим. Двусторонние адаптеры классов способны обеспечить такую прозрачность. Точнее, они полезны в тех случаях, когда клиент должен видеть объект по-разному.
    Для примера можно привести двусторонний адаптер, который интегрирует каркас графических редакторов Unidraw и библиотеку для разрешения ограничений QOCA. В обеих системах – есть классы, явно представляющие переменные: в Unidraw это StateVariable, а в QOCA –ConstraintVariable. Чтобы заставить Unidraw работать совместно с QOCA, ConstraintVariable нужно адаптировать к StateVariable. А для того чтобы решения QOCA распространялись на Unidraw, StateVariable следует адаптировать к ConstraintVariable.

    Здесь применен двусторонний адаптер класса ConstraintStateVariable, который является подклассом одновременно StateVariable и ConstraintVariable и адаптирует оба интерфейса друг к другу. Множественное наследование в данном случае вполне приемлемо, поскольку интерфейсы адаптированных классов существенно различаются. Двусторонний адаптер класса соответствует интерфейсам каждого из адаптируемых классов и может работать в любой системе, т.е. и в QOCA и в Unidraw в данном случае.
Рассмотрим 3 способа реализации сменных адаптеров для описанного выше виджета TreeDisplay, который может автоматически отображать иерархические структуры. Первый шаг, общий для всех трех реализаций, - найти «узкий» интерфейс для Adaptee, то есть наименьшее подмножество операций, позволяющее выполнить адаптацию. «Узкий» интерфейс, состоящий всего из пары итераций, легче адаптировать, чем интерфейс из нескольких десятков операций. Для TreeDisplay адаптации подлежит любая иерархическая структура. Минимальный интерфейс мог бы включать всего две операции:
  1. Определение графическое представление узла в иерархической структуре.
  2. Доступ к потомкам узла.
«Узкий» интерфейс приводит к трем подходам к реализации:
  1. Использование абстрактных операций.
    Определим в классе TreeDisplay абстрактные операции, которые соответствуют «узкому» интерфейсу класса Adaptee. И для каждого нового вида иерархичной структуры мы будем создавать по подклассу, который будет инкапсулировать объект своей конкретной структуру. Далее подкласс реализует эти абстрактные операции, пользуясь своим внутренним классом, и таким образом адаптирует иерархически структурированный объект. Например, подкласс DirectoryTreeDisplay, например, при их реализации будет осуществлять доступ к структуре каталогов файловой системы. А подкласс ManagerTreeDisplay специализирует узкий интерфейс таким образом, чтобы он мог отображать иерархию управленцев, составленную из объектов Manager.

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

  2. Использование объектов-уполномоченных.
    При таком подходе TreeDisplay инкапсулирует в себе объект уполномоченного и переадресует ему запросы на доступ к иерархической структуре. Таким образом TreeDisplay может реализовывать различные стратегии адаптации, подставляя разных уполномоченных.
    Например, предположим, что существует класс DirectoryBrowser, который использует TreeDisplay. DirectoryBrowser сам по себе может быть еще и уполномоченным для адаптации TreeDisplay к иерархической структуре каталогов.

    В статически типизированных языках вроде Java, C++, C# для этого потребуется явно реализовать интерфейс уполномоченного. Специфицировать такой интерфейс можно, поместив «узкий» интерфейс, который необходим классу TreeDisplay, в абстрактный класс TreeAccessorDelegate. После этого допустимо добавить этот интерфейс к выбранному уполномоченному - в данном случае DirectoryBrowser - с помощью наследования.
    Если у DirectoryBrowser еще нет существующего родительского класса, то воспользуемся одиночным наследованием, если есть – множественным (когда множественное наследование невозможно, TreeAccessorDelegate – делается интерфейсом). Подобное смешивание классов проще, чем добавление нового подкласса и реализация его операций по отдельности.
    В динамически типизированных языках вроде Smalltalk или Objective С такой подход требует интерфейса для регистрации уполномоченного в адаптере. Тогда TreeDisplay просто переадресует запросы уполномоченному. В системе NEXTSTEP этот подход активно используется для уменьшения числа подклассов.
  3. Параметризованные адаптеры.
    Обычно в Smalltalk для поддержки сменных адаптеров параметризуют адаптер одним или несколькими блоками.
    Конструкция блока поддерживает адаптацию без порождения подклассов. Блок может адаптировать запрос, а адаптер может хранить блок для каждого отдельного запроса. В нашем примере это означает, что TreeDisplay хранит 1 блок для преобразования узла в GraphicNode, а другой – для доступа к потомкам узла.
    Например, чтобы создать класс TreeDisplay для отображения иерархии каталогов, мы пишем:
     Параметризованный адаптер [smalltalk]  ссылка
    1. directoryDisplay :=
    2. (TreeDisplay on: treeRoot)
    3. getChiIdrenBlock:
    4. [:node | node getSubdirectories]
    5. createGraphicNodeBlock:
    6. [:node | node createGraphicNode]

    Если вы встраиваете интерфейс адаптации в класс, то этот способ дает удобную альтернативу подклассам.

Результаты

Результаты применения адаптеров объектов и классов различны.
Адаптер класса:
  1. Адаптирует Adaptee к Target, перепоручая действия конкретному классу Adaptee.
    Т.к. здесь напрямую используется наследование, данный паттерн не будет работать, если мы захотим одновременно адаптировать и класс, и его подклассы.
  2. Позволяет адаптеру Adapter заместить некоторые операции адаптируемого класса Adaptee, так как Adapter есть не что иное, как подкласс Adaptee
  3. Вводит только один новый объект.
    Чтобы добраться до адаптируемого класса, не нужно никакого дополнительного обращения по указателю (применительно к языкам имеющим указатели наподобие как в C++).
 
Адаптер объектов:
  1. Позволяет одному адаптеру Adapter работать со многим адаптируемыми объектами Adaptee
    Т.е. с самим Adaptee и его подклассами (если таковые имеются). Адаптер может добавить новую функциональность сразу всем адаптируемым объектам
  2. Затрудняет замещение операций класса Adaptee.
    Для этого потребуется породить от Adaptee подкласс и заставить Adapter ссылаться на этот подкласс, а не на сам Adaptee.

Пример

В многопользовательской системе определена сущность оператор(Operator), на которую возлагаются определенные обязанности: Operator.

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

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

В итоге - классический способ использования паттерна Адаптер: оборачиваем имеющийся класс User в новый класс адаптера(OperatorUser), и имплементируем целевой интерфейс Operator, используя интерфейс класса User: OperatorUserAdapter.

При этом в данном случае можно также реализовать и вариант двустороннего адаптера, заменив агрегирование сущности User – наследованием от нее. В итоге полученный адаптер мы сможем свободно (прозрачно) использовать и там где требуется Operator, и там, где User: OperatorUser.

Известные применения паттерна Адаптер (Adapter)

Пример, приведенный в разделе Условия, Задача, Назначение, заимствован из графического приложения ET++Draw, основанного на каркасе ЕТ++. ET++Draw повторно использует классы ЕТ++ для редактирования текста, применяя для адаптации класс TextShape.
В библиотеке Interviews 2.6 определен абстрактный класс Interactor для таких элементов пользовательского интерфейса, как полосы прокрутки, кнопки и меню. Есть также абстрактный класс Graphic для структурированных графических объектов: прямых, окружностей, многоугольников и сплайнов.
И Interactor, и Graphic имеют графическое представление, но у них разные интерфейсы и реализации (общих родительских классов нет), и значит, они несовместимы: нельзя непосредственно вложить структурированный графический объект, скажем, в диалоговое окно.
Вместо этого Interviews 2.6 определяет адаптер объектов GraphicBlock - подкласс Interactor, который содержит экземпляр Graphic. GraphicBlock адаптирует интерфейс класса Graphic к интерфейсу Interactor, позволяет отображать, прокручивать и изменять масштаб экземпляра Graphic внутри структуры класса Interactor.
Сменные адаптеры широко применяются в системе ObjectWorks\Smalltalk. В стандартном Smalltalk определен класс ValueModel для видов, которые отображают единственное значение. ValueModel определяет интерфейс value, value: для доступа к значению. Это абстрактные методы. Авторы приложений обращаются к значению по имени, более соответствующему предметной области, например width и width:, но они не обязаны порождать от ValueModel подклассы для адаптации таких зависящих от приложения имен к интерфейсу ValueModel.

Вместо этого ObjectWorks\Smalltalk включает подкласс ValueModel, называющийся PluggableAdaptor. Объект этого класса адаптирует другие объекты к интерфейсу ValueModel (value, value:). Его можно параметризовать блоками для получения и установки нужного значения. Внутри PluggableAdaptor эти блоки используются для реализации интерфейса value, value:. Этот класс позволяет также передавать имена селекторов (например, width, width:) непосредственно, обеспечивая тем самым некоторое синтаксическое удобство. Данные селекторы преобразуются в соответствующие блоки автоматически.

Еще один пример из ObjectWorks\Smalltalk - это класс TableAdaptor. Он может адаптировать последовательность объектов к табличному представлению.В таблице отображается по одному объекту в строке. Клиент параметризует TableAdaptor множеством сообщений, которые используются таблицей для получения от объекта значения в колонках.
В некоторых классах библиотеки NeXT AppKit используются объекты-уполномоченные для реализации интерфейса адаптации. В качестве примера можно привести класс NXBrowser, который способен отображать иерархические списки данных. NXBrowser пользуется объектом-уполномоченным для доступа и адаптации данных.

Придуманная Скоттом Мейером (Scott Meyer) конструкция «брак по расчету» (Marriage of Convenience) это разновидность адаптера класса. Мейер описывает, как класс FixedStack адаптирует реализацию класса Array к интерфейсу класса Stack. Результатом является стек, содержащий фиксированное число элементов.

Родственные паттерны

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

изменяет его интерфейс.

 

Реализации:

java(4)   +добавить

1) Operator.java на java, code #437[автор:this]
2) User.java на java, code #438[автор:this]
3) OperatorUserAdapter.java на java, code #439[автор:this]
4) OperatorUser.java на java, code #440[автор:this]