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

Мотивация

1. Реализуя интерфейс Shape, и наследуясь от Text View
2. Включив экземпляр TextView в TextShape и реализовав TextShape (т.е. рализовав интерфейс Shape) используя интерфейс класса TextView, т.е. попросту пользуясь классом TextView.

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

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

Решение

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

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

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

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

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 в данном случае.

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]  ссылка
   

   directoryDisplay :=
     (TreeDisplay on: treeRoot)
       getChiIdrenBlock:
         [:node | node getSubdirectories]
       createGraphicNodeBlock:
         [:node | node createGraphicNode]

   directoryDisplay := (TreeDisplay on: treeRoot) getChiIdrenBlock: [:node | node getSubdirectories] createGraphicNodeBlock: [:node | node createGraphicNode]
   Если вы встраиваете интерфейс адаптации в класс, то этот способ дает удобную альтернативу подклассам.

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

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

Пример

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

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

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

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

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

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