Адаптер - это структурный паттерн, который позволяет подружить несовместимые объекты.
Адаптер выступает прослойкой между двумя объектами, превращая вызовы одного в вызовы понятные другому.
Особенности паттерна на Java
Сложность:
Популярность:
Применимость: Паттерн можно часто встретить в Java-коде, особенно там, где требуется конвертация разных типов данных или совместная работа классов с разными интерфейсами.
Примеры Адаптеров в стандартных библиотеках Java:
- java.io.InputStreamReader(InputStream) (возвращает объект Reader)
- java.io.OutputStreamWriter(OutputStream) (возвращает объект Writer)
- javax.xml.bind.annotation.adapters.XmlAdapter#marshal() и #unmarshal()
Признаки применения паттерна: Адаптер получает конвертируемый объект в конструкторе или через параметры своих методов. Методы Адаптера обычно совместимы с интерфейсом одного объекта. Они делегируют вызовы вложенному объекту, превратив перед этим параметры вызова в формат, поддерживаемый вложенным объектом.
Помещение квадратных колышков в круглые отверстия
Этот простой пример показывает как с помощью паттерна Адаптер можно совмещать несовместимые вещи.
round
round/RoundHole.java: Круглое отверстие
package сайт.adapter.example.round; /** * КруглоеОтверстие совместимо с КруглымиКолышками. */ public class RoundHole { private double radius; public RoundHole(double radius) { this.radius = radius; } public double getRadius() { return radius; } public boolean fits(RoundPeg peg) { boolean result; result = (this.getRadius() >= peg.getRadius()); return result; } }round/RoundPeg.java: Круглый колышек
package сайт.adapter.example.round; /** * КруглыеКолышки совместимы с КруглымиОтверстиями. */ public class RoundPeg { private double radius; public RoundPeg() {} public RoundPeg(double radius) { this.radius = radius; } public double getRadius() { return radius; } }square
square/SquarePeg.java: Квадратный колышек
package сайт.adapter.example.square; /** * КвадратныеКолышки несовместимы с КруглымиОтверстиями (они остались в проекте * после бывших разработчиков). Но мы должны как-то интегрировать их в нашу * систему. */ public class SquarePeg { private double width; public SquarePeg(double width) { this.width = width; } public double getWidth() { return width; } public double getSquare() { double result; result = Math.pow(this.width, 2); return result; } }adapters
adapters/SquarePegAdapter.java: Адаптер квадратных колышков к круглым отверстиям
package сайт.adapter.example..adapter.example.round..adapter.example.square.SquarePeg; /** * Адаптер позволяет использовать КвадратныеКолышки и КруглыеОтверстия вместе. */ public class SquarePegAdapter extends RoundPeg { private SquarePeg peg; public SquarePegAdapter(SquarePeg peg) { this.peg = peg; } @Override public double getRadius() { double result; // Рассчитываем минимальный радиус, в который пролезет этот колышек. result = (Math.sqrt(Math.pow((peg.getWidth() / 2), 2) * 2)); return result; } }Demo.java: Клиентский код
package сайт.adapter..adapter.example.adapters..adapter.example.round..adapter.example.round..adapter.example.square.SquarePeg; /** * Где-то в клиентском коде... */ public class Demo { public static void main(String args) { // Круглое к круглому - всё работает. RoundHole hole = new RoundHole(5); RoundPeg rpeg = new RoundPeg(5); if (hole.fits(rpeg)) { System.out.println("Round peg r5 fits round hole r5."); } SquarePeg smallSqPeg = new SquarePeg(2); SquarePeg largeSqPeg = new SquarePeg(20); // hole.fits(smallSqPeg); // Не скомпилируется. // Адаптер решит проблему. SquarePegAdapter smallSqPegAdapter = new SquarePegAdapter(smallSqPeg); SquarePegAdapter largeSqPegAdapter = new SquarePegAdapter(largeSqPeg); if (hole.fits(smallSqPegAdapter)) { System.out.println("Square peg w2 fits round hole r5."); } if (!hole.fits(largeSqPegAdapter)) { System.out.println("Square peg w20 does not fit into round hole r5."); } } }OutputDemo.txt: Результат выполнения
Round peg r5 fits round hole r5. Square peg w2 fits round hole r5. Square peg w20 does not fit into round hole r5.Назначение
Адаптер (англ. Adapter или англ. Wrapper -Обёртка) - структурный шаблон проектирования, предназначенный для организации использования функций объекта, недоступного для модификации, через специально созданный интерфейс.
Задача
Система поддерживает требуемые данные и поведение, но имеет неподходящий интерфейс.
Способ решения
Адаптер предусматривает создание класса-оболочки с требуемым интерфейсом.
Участники
Класс Adapter приводит интерфейс класса Adaptee в соответствие с интерфейсом класса Target (наследником которого является Adapter). Это позволяет объекту Client использовать объект Adaptee (посредством адаптера Adapter) так, словно он является экземпляром класса Target .
Таким образом Client обращается к интерфейсу Target , реализованному в наследнике Adapter, который перенаправляет обращение к Adaptee.
UML-диаграмма классов паттерна Adapter
Следствия
Шаблон Адаптер позволяет включать уже существующие объекты в новые объектные структуры, независимо от различий в их интерфейсах.
Описание
Пусть класс, интерфейс которого нужно адаптировать к нужному виду, имеет имя Adaptee. Для решения задачи преобразования его интерфейса паттерн Adapter вводит следующую иерархию классов:
Виртуальный базовый класс Target. Здесь объявляется пользовательский интерфейс подходящего вида. Только этот интерфейс доступен для пользователя.
Производный класс Adapter, реализующий интерфейс Target. В этом классе также имеется указатель или ссылка на экземпляр Adaptee. Паттерн Adapter использует этот указатель для перенаправления клиентских вызовов в Adaptee. Так как интерфейсы Adaptee и Target несовместимы между собой, то эти вызовы обычно требуют преобразования.
Паттерн Adapter, представляющий собой программную обертку над существующими классами, преобразует их интерфейсы к виду, пригодному для последующего использования.
Рассмотрим простой пример, когда следует применять паттерн Adapter. Пусть мы разрабатываем систему климат-контроля, предназначенной для автоматического поддержания температуры окружающего пространства в заданных пределах. Важным компонентом такой системы является температурный датчик, с помощью которого измеряют температуру окружающей среды для последующего анализа. Для этого датчика уже имеется готовое программное обеспечение от сторонних разработчиков, представляющее собой некоторый класс с соответствующим интерфейсом. Однако использовать этот класс непосредственно не удастся, так как показания датчика снимаются в градусах Фаренгейта. Нужен адаптер, преобразующий температуру в шкалу Цельсия.
Реализация
|
namespace Adapter static void Main() // Create adapter and place a request Target target = new Adapter(); target.Request(); // Wait for user public virtual void Request() Console.WriteLine("Called Target Request()"); class Adapter: Target private Adaptee adaptee = new Adaptee(); public override void Request() // Possibly do some other work // and then call SpecificRequest adaptee.SpecificRequest(); public void SpecificRequest() Console.WriteLine("Called SpecificRequest()"); |
Результаты применения паттерна 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.
Позже выложу код использования Адаптеров из реальных проектов, в которых я принимал участие, а пока жду ваших вопросов и комментариев. Удачи.
В прошлом уроке мы рассмотрели возможность шаблона проектирования Фасад, с помощью которого можно перестроить код крупного проекта.
В этой статье под наш прицел попал шаблон проектирования под названием Адаптер. Его использование целесообразно, если в вашем проекте происходит взаимодействие с сторонними 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, так что использование шаблона проектирования Адаптер целесообразно, если вы хотите избежать рассмотренной нами проблемы.
Я сделал всё зависящее от меня, чтобы продемонстрировать элементарный и одновременно полезный пример использования шаблона проектирования Адаптер.
В прошлом уроке мы рассмотрели возможность шаблона проектирования Фасад, с помощью которого можно перестроить код крупного проекта.
В этой статье под наш прицел попал шаблон проектирования под названием Адаптер. Его использование целесообразно, если в вашем проекте происходит взаимодействие с сторонними 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, так что использование шаблона проектирования Адаптер целесообразно, если вы хотите избежать рассмотренной нами проблемы.
Я сделал всё зависящее от меня, чтобы продемонстрировать элементарный и одновременно полезный пример использования шаблона проектирования Адаптер.