Адаптер шаблон проектирования. Структурные шаблоны: Адаптер (Adapter)

В прошлом уроке мы рассмотрели возможность шаблона проектирования Фасад, с помощью которого можно перестроить код крупного проекта.

В этой статье под наш прицел попал шаблон проектирования под названием Адаптер. Его использование целесообразно, если в вашем проекте происходит взаимодействие с сторонними API, или другим классом, который подвержен частым изменениям. Данный шаблон относится к "структурному" типу т.к. с его помощью мы можем мы можем организовать структуру классов по определённому образцу.

Ещё раз хотел бы напомнить, что шаблоны проектирования ничем не отличаются от обычных классов. С их помощью мы можем лучшим способом структурировать наши классы, управлять их поведением.

Задача

В приведённом примере мы используем класс Twitter для упрощения процедуры публикации сообщения. Далее мы создаём объект для обращения к Twitter API и публикации сообщения. Представьте, что данный код используется в нескольких местах. Обратите внимание, что для публикации сообщения мы используем метод $twitter->send("Posting on Twitter");

Некоторое время назад, Twitter изменили название метода API для публикации сообщения. Те, кто пользовался предыдущей версией явно увидят сложившуюся проблему. Нам необходимо поменять все названия методов для отправки твитта. Представьте сколько кода нам нужно поменять и сколько на это потребуется времени. Что если смена названия произойдёт ещё раз?

Решение

В качестве решения можем применить шаблон проектирования Адаптер.

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

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

Давайте рассмотрим код, написанный на основе шаблона проектирования Адаптер:

// Имплементация класса Twitter class Twitter { public function __construct() { // Your Code here // } public function send($msg) { // Posting to Twitter // echo $msg; } } // Простой интерфейс для каждого адаптера, который будет создан interface socialAdapter { public function send($msg); } class twitterAdapter implements socialAdapter { private $twitter; public function __construct(Twitter $twitter) { $this->twitter = $twitter; } public function send($msg) { $this->twitter->send($msg); } }

Изучив код вы поймёте, что мы не тронули исходный класс Twitter. Вместо этого мы создали интерфейс нашего социального адаптера для класса Twitter.

Далее вместо создания объекта типа Twitter, мы создали объект его адаптера. В качестве параметра передаём объект основного класса Twitter, для того, чтобы наш адаптер имел доступ к объекту основного класса.

Теперь давайте определим как использовать методы исходного класса:

// клиентский код $twitter = new twitterAdapter(new Twitter()); $twitter->send("Posting to Twitter");

Теперь представьте, что Twitter изменил название метода с send на sendTweet. В этом случае, нам нужно изменить только twitterAdapter. Взгляните на изменённый код адаптера.

Class twitterAdapter implements socialAdapter { private $twitter; public function __construct(Twitter $twitter) { $this->twitter = $twitter; } public function send($msg) { $this->twitter->sendTweet($msg); } }

Только одно изменение и мы снова в теме.

Добавление нового адаптера

Давайте рассмотрим как можно использовать шаблон проектирования Адаптер в других случаях. Теперь очень просто добавить новый класс на основе существующего адаптера. Допустим Facebook API позволяет обновить статус.

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

Class Facebook { public function __construct() { // Ваш код // } public function updateStatus($msg) { // Пост на Facebook // echo $msg; } } // Адаптер Facebook class facebookAdapter implements socialAdapter { private $facebook; public function __construct(Facebook $facebook) { $this->facebook = $facebook; } public function send($msg) { $this->facebook->updateStatus($msg); } } // клиентский код $facebook = new facebookAdapter(new Facebook()); $facebook->send("Posting to Facebook");

Как видите, принцип тот же. Вы определяете класс оболочку, в который передаёте оригинальный объект класса. При изменении API, вам нужно сменить код только в одном месте.

Заключение

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

Я сделал всё зависящее от меня, чтобы продемонстрировать элементарный и одновременно полезный пример использования шаблона проектирования Адаптер.

Паттерн Адаптер, Обертка (Adapter, Wrapper)

Название и классификация паттерна

Адаптер - паттерн, структурирующий как классы, так и объекты.

Назначение паттерна Adapter

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

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

Рассмотрим простейший пример применения паттерна Adapter. Пусть мы разрабатываем систему климат-контроля. Важным компонентом такой системы является температурный датчик, для которого уже имеется готовое программное обеспечение, представляющее собой некоторый класс с соответствующим интерфейсом для работы со шкалой Фаренгейта. Но нас интересует температура по шкале Цельсия. Задача может быть легко решена с помощью паттерна Adapter.

Рассмотрим другой пример - графический редактор, в котором пользователи могут рисовать на экране графические элементы (линии, многоугольники, текст и т. д.) и организовывать их в виде картинок и диаграмм. Основной абстракцией графического редактора является графический объект, который имеет изменяемую форму и изображает сам себя. Интерфейс графических объектов определен абстрактным классом Shape. Редактор определяет подкласс класса Shape для каждого вида графических объектов: LineShape для прямых, PolygonShape для многоугольников и т. д.

Классы для элементарных геометрических фигур, например LineShape и PolygonShape, реализовать сравнительно просто, поскольку заложенные в них возможности рисования и редактирования крайне ограниченны. Но подкласс Text Shape, умеющий отображать и редактировать текст, уже значительно сложнее. В то же время существуют готовые библиотеки для разработки пользовательских интерфейсов, предоставляющие развитый класс Text View для отображения и редактирования текста.

Можно было бы так изменить интерфейс класса Text View, чтобы он соответствовал интерфейсу Shape, только для этого нужен исходный код. Но даже если он доступен, то вряд ли разумно изменять Text View - библиотека не должна приспосабливаться к интерфейсам каждого конкретного приложения.

Вместо этого можно так определить класс Text Shape, что он будет адаптировать интерфейс Text View к интерфейсу Shape. Это допустимо сделать двумя способами: наследуя интерфейс от Shape, а реализацию от Text View; включив экземпляр Text View в Text Shape и реализовав Text Shape в терминах интерфейса Text View. Два данных подхода соответствуют вариантам паттерна Адаптер в его классовой и объектной ипостасях. Класс Text Shape (рис. 40) мы будем называть Адаптером.

На диаграмме показан Адаптер объекта. Видно, как запрос BoundingBox, объявленный в классе Shape, преобразуется в запрос Get Extent, определенный в классе Text View. Поскольку класс Text Shape адаптирует Text View к интерфейсу Shape, графический редактор может воспользоваться классом TextView, хотя тот и имеет несовместимый интерфейс.

Часто Адаптер отвечает за функциональность, которую не может предоставить адаптируемый класс. На рис. 40 показано, как Адаптер

return newTextManipulator^^

Рис. 40. UML-диаграмма Адаптера объекта

выполняет такого рода функции. У пользователя должна быть возможность перемещать любой объект класса Shape в другое место, но в классе TextView такая операция не предусмотрена. Text Shape может добавить недостающую функциональность, самостоятельно реализовав операцию CreateManipulator класса Shape, которая возвращает экземпляр подходящего подкласса Manipulator.

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

Применимость

Применяйте паттерн Адаптер, когда:

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

Описание паттерна Adapter

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

Пусть класс, интерфейс которого нужно адаптировать к нужному виду, имеет имя Adapt?e. Для решения задачи преобразования его интерфейса паттерн Adapter вводит следующую иерархию классов:

виртуальный базовый класс Target. Здесь объявляется пользовательский интерфейс подходящего вида. Только этот интерфейс доступен для пользователя;
производный класс Adapter , реализующий интерфейс Target. В этом классе также имеется указатель или ссылка на экземпляр Adapt?e. Паттерн Adapter использует этот указатель для перенаправления клиентских вызовов в Adapt?e. Так как интерфейсы Adapt?e и Target несовместимы между собой, то эти вызовы обычно требуют преобразования.

Структура

Структура паттерна Адаптер показана на рис. 41.

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

adaptee->specificRequest()

Рис. 41. UML-диаграмма классов паттерна Adapter

Участники

Target (Shape) - целевой: определяет зависящий от предметной области интерфейс, которым пользуется Client.

Client (DrawingEditor) - клиент: вступает во взаимоотношения с объектами, удовлетворяющими интерфейсу Target.

Adapt?e (Textview) - адаптируемый: определяет существующий интерфейс, который нуждается в адаптации.

Adapter (Text Shape) - Адаптер: адаптирует интерфейс Adapt?e к интерфейсу Target.

Отношения

Клиенты вызывают операции экземпляра Адаптера Adapter. В свою очередь, Адаптер вызывает операции адаптируемого объекта или класса Adapt?e, который и выполняет запрос.

Результаты

Результаты применения Адаптеров объектов и классов различны.

Адаптер класса:

адаптирует Adapt?e к Target, перепоручая действия конкретному классу Adapt?e. Поэтому данный паттерн не будет работать, если мы захотим одновременно адаптировать класс и его подклассы;
позволяет Адаптеру Adapter заместить некоторые операции адаптируемого класса Adapt?e, так как Adapter есть не что иное, как подкласс Adapt?e;
вводит только один новый объект. Чтобы добраться до адаптируемого класса, не нужно никакого дополнительного обращения по указателю.

Адаптер объектов:

позволяет одному Адаптеру Adapter работать со многим адаптируемыми объектами Adapt?e, т. е. с самим Adapt?e и его подклассами (если таковые имеются). Адаптер может добавить новую функциональность сразу всем адаптируемым объектам;
затрудняет замещение операций класса Adapt?e. Для этого потребуется породить от Adapt?e подкласс и заставить Adapter ссылаться на этот подкласс, а не на сам Adapt?e.

Адаптеры сильно отличаются по тому объему работы, который необходим для адаптации интерфейса Adapt?e к интерфейсу Target. Это может быть как простейшее преобразование, например изменение имен операций, так и поддержка совершенно другого набора операций. Объем работы зависит от того, насколько сильно отличаются друг от друга интерфейсы целевого и адаптируемого классов.

На первом шаге реализации необходимо найти «узкий» интерфейс для Adapt?e, т. е. наименьшее подмножество операций, позволяющее выполнить адаптацию. «Узкий» интерфейс, состоящий всего из пары итераций, легче адаптировать, чем интерфейс из нескольких десятков операций.

«Узкий» интерфейс можно реализовать разными способами.

1. Использование абстрактных операций. Подклассы должны реализовывать эти абстрактные операции и адаптировать иерархически структурированный объект.
2. Использование объектов-уполномоченных. При таком подходе запросы на доступ к иерархической структуре переадресуются объек-ту-уполномоченному.

Классическая реализация паттерна Adapter

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

// Уже существующий класс температурного датчика окружающей среды

class FahrenheitSensor

// Получить показания температуры в градусах Фаренгейта float getFahrenheitTemp() { float t = 32.0;

//... какой-то код return t;

virtual ~Sensor() {}

class Adapter: public Sensor

Adapter(FahrenheitSensor* p): p_fsensor(p) {

Adapted) { delete p_fsensor;

float getTemperature() { return (p_fsensor->getFahrenheitTemp()-32.0)*5.0/9.0;

FahrenheitSensor* p_fsensor;

Sensor* p = new Adapter(new FahrenheitSensor);

cout getTemperature()

Реализация паттерна Adapter на основе закрытого наследования

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

Разрабатываемая нами система должна поддерживать настройку измерений. Так как доступ к защищенному методу через указатель или ссылку запрещен, то классическая реализация паттерна Adapter здесь уже не подходит. Единственное решение - наследовать от класса FahrenheitSensor. Интерфейс этого класса должен оставаться недоступным пользователю, поэтому наследование должно быть закрытым.

Цели, преследуемые при использовании открытого и закрытого наследования, различны. Если открытое наследование применяется для наследования интерфейса и реализации, то закрытое наследование - только для наследования реализации.

class FahrenheitSensor

float getFahrenheitTempO { float t = 32.0;

void adjustQ {} // Настройка датчика (защищенный метод)

virtual ~Sensor() {}

virtual float getTemperature() = 0;

virtual void adjust() = 0;

class Adapter: public Sensor, private FahrenheitSensor

Adapter() {} float getTemperature() { return (getFahrenheitTemp()-32.0)*5.0/9.0;

FahrenheitSensor::adjust();

Sensor * p = new Adapter(); p->adjust();

cout getTemperature()

Результаты применения паттерна Adapter

Достоинства паттерна Adapter

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

Недостатки паттерна Adapter

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

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

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

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

Заместитель определяет представителя или суррогат другого объекта, но не изменяет его интерфейс.

Вернемся к рассмотрению структурных паттернов проектирования. На этот раз мы рассмотрим шаблон проектирования под названием Adapter (его еще называют Wrapper на ряду с паттерном Facade).

В этой статье поговорим о следующем:

Итак, паттерн Adapter используется для того, чтобы объекты с одним интерфейсом (контрактом) мог работать там, где необходим объект с совершенно другим интерфейсом. Существует два типа адаптеров - Class Adapter и Object Adapter.

Для начала мы рассмотрим каждый из этих типов, а потом я объясню разницу между двумя wrapper"ами - адаптером и фасадом.

Object Adapter

Object Adapter достигает своей цели с помощью композиции. На диаграмме, представленной ниже, клиенту требуется использовать интерфейс TargetInterface. Для этого создается класс ObjectAdapter, который реализует интерфейс TargetInterface, а также хранит объект класса Adaptee. При вызове метода targetMethod у Адаптера, осуществляется вызов соответствующего метода у адаптируемого интерфейса.

В самом простом случае реализация ObjectAdapter будет такой:

Public class ObjectAdapter implements TargetInterface { private Adaptee adaptee; public void targetMethod() { adaptee.method() } }

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

Class Adapter

В случае с Class Adapter"ом, для достижения нашей цели используется множественное наследование. Наш ClassAdapter наследуется от клиентского интерфейса и от Адаптируемого интерфейса. Так как в Java нет множественного наследования, то только один из предков может быть абстрактным/конкретным классом. Второй предок будет интерфейсом, что не всегда удобно.

Диаграмма классов:

А вот и тривиальная реализация класса ClassAdapter:

Public class ClassAdapter extends Adaptee implements TargetInterface { public void targetMethod() { method(); } }

Хочу обратить ваше внимание, что при такой реализации адаптера может возникнуть конфликт сигратур методов. Такой проблемы у Object Adapter нет.

Class Adapter считается более простым решением в случае когда не требуется жесткого разделения клиентского и адаптируемого интерфейсов.

Разница между Адаптером и Фасадом

Теперь хочу сказать несколько слов по поводу паттерна Фасад, который как и Адаптер является Wrapper"ом. Facade определяет новый интерфейс, в то время как Адаптер использует существующие интерфейсы.

Не стоит сравнивать Фасад и Адаптер так: мол, Фасад может оборачивать несколько классов, а Адаптер адаптирует только один. Очень может быть, что Адаптер понадобится для адаптации нескольких классов и наоборот, Фасад придется использовать для упрощения всего лишь одного комплексного класса. Так что разница этих двух паттернов не в количестве оборачиваемых сущностей, а в том, для чего они это делают.

Пример использования Адаптера в JDK

В стандартной библиотеке тоже можно встретить примеры использования Адаптера. Наверное, самый популярный вариант использования - это java.io.InputStreamReader и OutputStreamWriter.

Конструктор InputStreamReader принимает на вход InputStream и в результате адаптирует поток в Reader.

Позже выложу код использования Адаптеров из реальных проектов, в которых я принимал участие, а пока жду ваших вопросов и комментариев. Удачи.

Задача

Решение

В качестве решения можем применить шаблон проектирования Адаптер.

Давайте рассмотрим код, написанный на основе шаблона проектирования Адаптер:

Теперь давайте определим как использовать методы исходного класса:

// клиентский код $twitter = new twitterAdapter(new Twitter()); $twitter->send("Posting to Twitter");

Только одно изменение и мы снова в теме.

Добавление нового адаптера

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

Заключение

Назначение паттерна Adapter

Рассмотрим простой пример, когда следует применять паттерн Adapter. Пусть мы разрабатываем систему климат-контроля, предназначенной для автоматического поддержания температуры окружающего пространства в заданных пределах. Важным компонентом такой системы является температурный датчик, с помощью которого измеряют температуру окружающей среды для последующего анализа. Для этого датчика уже имеется готовое программное обеспечение от сторонних разработчиков, представляющее собой некоторый класс с соответствующим интерфейсом. Однако использовать этот класс непосредственно не удастся, так как показания датчика снимаются в градусах Фаренгейта. Нужен адаптер, преобразующий температуру в шкалу Цельсия.

Контейнеры queue, priority_queue и stack библиотеки стандартных шаблонов STL реализованы на базе последовательных контейнеров list, deque и vector, адаптируя их интерфейсы к нужному виду. Именно поэтому эти контейнеры называют контейнерами-адаптерами.

Описание паттерна Adapter

Пусть класс, интерфейс которого нужно адаптировать к нужному виду, имеет имя Adaptee. Для решения задачи преобразования его интерфейса паттерн Adapter вводит следующую иерархию классов:

Виртуальный базовый класс Target. Здесь объявляется пользовательский интерфейс подходящего вида. Только этот интерфейс доступен для пользователя.
Производный класс Adapter, реализующий интерфейс Target. В этом классе также имеется указатель или ссылка на экземпляр Adaptee. Паттерн Adapter использует этот указатель для перенаправления клиентских вызовов в Adaptee. Так как интерфейсы Adaptee и Target несовместимы между собой, то эти вызовы обычно требуют преобразования.

Реализация паттерна Adapter

Классическая реализация паттерна Adapter

#include // Уже существующий класс температурного датчика окружающей среды class FahrenheitSensor { public: // Получить показания температуры в градусах Фаренгейта float getFahrenheitTemp() { float t = 32.0; // ... какой то код return t; } }; class Sensor { public: virtual ~Sensor() {} virtual float getTemperature() = 0; }; class Adapter: public Sensor { public: Adapter(FahrenheitSensor* p) : p_fsensor(p) { } ~Adapter() { delete p_fsensor; } float getTemperature() { return (p_fsensor->getFahrenheitTemp()-32.0)*5.0/9.0; } private: FahrenheitSensor* p_fsensor; }; int main() { Sensor* p = new Adapter(new FahrenheitSensor); cout << "Celsius temperature = " << p->getTemperature() << endl; delete p; return 0; }

Реализация паттерна Adapter на основе закрытого наследования

Цели, преследуемые при использовании открытого и закрытого наследования различны. Если открытое наследование применяется для наследования интерфейса и реализации, то закрытое наследование - только для наследования реализации.

#include class FahrenheitSensor { public: float getFahrenheitTemp() { float t = 32.0; // ... return t; } protected: void adjust() {} // Настройка датчика (защищенный метод) }; class Sensor { public: virtual ~Sensor() {} virtual float getTemperature() = 0; virtual void adjust() = 0; }; class Adapter: public Sensor, private FahrenheitSensor { public: Adapter() { } float getTemperature() { return (getFahrenheitTemp()-32.0)*5.0/9.0; } void adjust() { FahrenheitSensor::adjust(); } }; int main() { Sensor * p = new Adapter(); p->adjust(); cout << "Celsius temperature = " << p->getTemperature() << endl; delete p; return 0; }

Результаты применения паттерна Adapter

Достоинства паттерна Adapter

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

Недостатки паттерна Adapter

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