Готовый код на адаптеры в java. Структурные шаблоны: Адаптер (Adapter)
Основная статья: Адаптер (шаблон проектирования) Пример реализации шаблона на C# using System; namespace Adapter { class MainApp { static void Main() { … Википедия
У этого термина существуют и другие значения, см. Паттерн. В разработке программного обеспечения, шаблон проектирования или паттерн (англ. design pattern) повторимая архитектурная конструкция, представляющая собой решение проблемы… … Википедия
Шаблон проектирования Интерфейс Interface Описан в Design Patterns Нет В информатике, шаблон интерфейса не является особым шаблоном среди шаблонов проектирования. Он является общим методом для структурирования компьютерных программ для того … Википедия
Шаблон Proxy (Заместитель) Шаблон проектирования. Предоставляет объект, контролирующий доступ, перехватывая все вызовы к нему. Содержание 1 Цель 1.1 Проблема 1.2 Решение 2 Плюсы 3 … Википедия
Шаблон проектирования Хранитель Memento Тип: поведенческий Описан в Design Patterns Да Хранитель (также известный как Memento, Token, Лексема) поведенческий шаблон проектирования. Позволяет, не нарушая инкапсуляцию, зафикс … Википедия
Шаблон проектирования Итератор Iterator Тип: поведенческий Описан в Design Patterns Да Шаблон Iterator (также известный как Cursor) Шаблон проектирования, относится к паттернам поведения. Представляет собой объект, позволяющий получить … Википедия
Шаблон проектирования Интерпретатор Interpreter Тип: поведенческий Назначение: решает часто встречающуюся, подверженную изменениям задачу Описан в Design Patterns Да Шаблон Интерпретатор (англ. … Википедия
Шаблон проектирования Компоновщик Composite Тип: структурный Описан в Design Patterns Да Компоновщик (англ. Composite pattern) шаблон проектирования, относится к структурным паттернам, объединяет объек … Википедия
Шаблон проектирования Состояние State Тип: поведенческий Описан в Design Patterns Да Состояние (англ. State) шаблон проектирования. Используется в тех случаях, когда во время выполнения программы объект … Википедия
Всем привет! Сегодня мы поговорим о шаблоне проектирования Адаптер(Pattern Adapter) . Как понятно из названия, служит он для того, чтобы что-то адаптировать , но вот что? А на этот вопрос вам ответит эта статья.
Описание шаблона проектирования Адаптер
Давайте немного отойдем от программирования и посмотрим на адаптеры в реальной жизни. К примеру, вы купили какую-то технику(например, компьютер) за границей. Приехав с ней домой, вы обнаружили, что вилка другого стандарта и в нашу, российскую розетку, не подходит. Что же делать? Правильно! Нужно пойти в магазин и купить переходник , используя который вы сможет подключить ваш компьютер в сеть. Так вот, этот переходник и есть адаптер . В него мы вставляем иностранную вилку, а сам адаптер включаем в сеть и все прекрасно работает. Т.е. он служит просто прослойкой между нашей розеткой и иностранной вилкой.
Итак, думаю, что вы разобрались, что такое адаптер в жизни. В программировании - это то же самое.
Пример реализации адаптера на PHP
interface iMain {public function send();
}
Interface iAdaptee {
public function inquiry();
}
Class Adaptee implements iAdaptee {
public function inquiry() {
return __CLASS__."::".__METHOD__;
}
}
Class Adapter implements iMain {
protected $adaptee = null;
Public function __construct() {
$this->adaptee = new Adaptee();
}
Public function send() {
return $this->adaptee->inquiry();
}
}
$goal = new Adapter();
echo $goal->send(); // "Adaptee::inquiry"
?>
Итак, вот наш код. Давайте разбираться. У нас есть интерфейс iMain , клиентский код умеет работать с ним. Дальше у нас есть интерфейс iAdaptee , с которым клиентский код работать не умеет, но нам необходимо как-то с ним взаимодействовать. Потом у нас есть класс Adaptee iAdaptee и внутри у него есть метод с именем inquiry , который просто возвращает строку вида CLASS::METHOD . Вот мы подошли к классу Adapter , который наследует интерфейс iMain . Внутри него мы создаем защищенное свойство adaptee , равное null . Дальше в конструкторе мы создаем объект класса Adaptee и записываем его в наше защищенное свойство. В методе send мы возвращаем вызов метода inquiry .
Вот и все. Теперь создаем объект нашего адаптера и вызываем метод send .
Т.е. вся суть в том, что мы можем работать с одним интерфейсом, но не можем с другим и, чтобы как-то взаимодействовать с этим недоступным нам интерфейсом, мы и создаем адаптер , прослойку, через которую и реализуем нашу задачу.
Заключение
Сейчас вам может показаться, что все очень сложно и трудно, но это не так. Думаю, смысл адаптера вы поняли, а теперь вам нужно больше практики. Просмотрите еще раз код, который дан в этой статье, и попытайтесь его осмыслить. Строчка за строчку просматривайте и проговаривайте его, как будто вы интерпретатор php . Также, советую просмотреть код какого-нибудь фреймворка, ведь там этот шаблон используется довольно часто.
На этом я заканчиваю эту немаленькую статью, спасибо за внимание!
В прошлом уроке мы рассмотрели возможность шаблона проектирования Фасад, с помощью которого можно перестроить код крупного проекта.
В этой статье под наш прицел попал шаблон проектирования под названием Адаптер. Его использование целесообразно, если в вашем проекте происходит взаимодействие с сторонними 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).
Тип
Структурный шаблон проектирования (Structural).
Описание
Шаблон Адаптер предназначен для приведения интерфейса объекта к требуемому виду.
Данный шаблон применяется если:
- существующий объект, называемый адаптируемым, предоставляет необходимые функции, но не поддерживает нужного интерфейса;
- (или) неизвестно заранее, с каким интерфейсами придется работать адаптируемому объекту;
- (или) формат входных или выходных данных метода не совпадает с требуемым.
Главная задача Адаптера – реализация требуемого интерфейса и трансляция его вызовов адаптируемому объекту. Подобную ситуацию можно встретить при использовании сторонних библиотек. Они далеко не всегда предоставляют интерфейсы, которые необходимы в для связи с другими объектами. При этом изменить код или добавить поддержку интерфейса не предоставляется возможным.
Иллюстрацией другого варианта использования может служить подключение модулей расширения. Предположим, что есть готовый компонент выполняющий нужные функции, но ничего не знающий о нужном для использования интерфейсе. Адаптер, в этом случае, будет играть роль переходника для подключения к интерфейсу системы расширений. При этом подключение новых компонентов может изменять функциональность приложения.
Еще один пример использования шаблона – адаптация поведения. Такой подход используется, например, в.NET при работе с COM объектами: полученные от них коды ошибок из значений типа HRESULT преобразуется в выбросы исключений типа COMExceptions .
Таким образом, цель Адаптера – предоставить возможность повторного использования существующего кода, независимо от отличий в интерфейсе или поведении. Кроме того, меняя адаптируемые объекты возможно влиять на функции, выполняемые в программе.
Различают четыре роли, отводимые участвующим в работе шаблона объектам:
- Адаптируемый объект (Adaptee);
- Цель (Target), определяющая требуемый интерфейс;
- Адаптер (Adapter);
- Клиент (Client), который умеет работать с только объектами, реализующими интерфейс цели.
Стоит принять во внимание следующие моменты:
- Адаптер не обязательно должен содержать только вызовы адаптируемого объекта. Он может заниматься обработкой входных и выходных данных, приводя их к нужному формату.
- В рамках шаблона можно использовать несколько адаптируемых объектов для реализации заданного интерфейса.
- Реализация шаблона может самостоятельно дополнить необходимую функциональность, если такой нет у адаптируемого объекта.
- Адаптер может работать не только с заданным адаптируемым объектом, но и его наследниками.
- Возможно замещение части методов адаптируемого объекта. В этом случае от него необходимо создать подкласс, в котором произвести нужные замещения. И уже результат использовать в Адаптере.
- Реализация адаптера может быть двухсторонней. В этом случае адаптируемый объект реализует промежуточную логику для связи двух целей, каждая из которых требует наличие своего интерфейса.
- Можно использовать Отложенную инициализацию для создания экземпляра адаптируемого объекта.
Схожие шаблоны и их отличия
| Адаптер | Изменяет интерфейс объекта не изменяя его функциональности. Может адаптировать несколько объектов к одному интерфейсу. | Позволяет повторно использовать уже существующий код. | Содержит или наследует адаптируемый объект. |
|---|---|---|---|
| Фасад | Объединяет группу объектов под одним специализированным интерфейсом. | Упрощает работу с группой объектов, вносит новый уровень абстракции. | Содержит или ссылается на объекты, необходимые для реализации специализированного интерфейса. |
| Мост | Разделяет объект на абстракцию и реализацию. Используется для иерархии объектов. | Позволяет отдельно изменять (наследовать) абстракцию и реализацию, повышая гибкость системы. | Содержит объект(реализацию), который предоставляет методы для заданной абстракций и ее уточнений (наследников). |
| Декоратор | Расширяет возможности объекта, изменяет его поведение. Поддерживает интерфейс декорируемого объекта, но может добавлять новые методы и свойства. | Дает возможность динамически менять функциональность объекта. Является альтернативой наследованию (в том числе множественному). | Содержит декорируемый объект. Возможна цепочка объектов, вызываемых последовательно. |
| Прокси | Прозрачно замещает объект и управляет доступом к нему. Не изменяет интерфейс или поведение. | Упрощает и оптимизирует работу с объектом. Может добавлять свою функциональность, скрывая ее от клиента. | Содержит объект или ссылку на него, может управлять существованием замещенного объекта. |
| Компоновщик | Предоставляет единый интерфейс для взаимодействия с составными объектами и их частями. | Упрощает работу клиента, позволяет легко добавлять новые варианты составных объектов и их частей. | Включается в виде интерфейса в составные объекты и их части. |
| Приспособленец | Не ставит целью изменение интерфейса объекта. Но это может потребоваться для получения обратно данных из вынесенной части состояния. | Позволяет уменьшить число экземпляров объекта в приложении и тем самым сэкономить его ресурсы. | Выносит контекстно-зависимую часть состояния объекта вовне, заменяя несколько его экземпляров одним. |
Реализация шаблона в общем виде
По схеме, используемой для работы с адаптируемым объектом, выделяют два варианта:
- Адаптер объекта – использует композицию, т.е. содержит экземпляр адаптируемого объекта.
- Адаптер класса – использует наследование от адаптируемого объекта для получения его функциональности.
Приоритетным является первый вариант, т.к. он обеспечивает меньшую связанность с адаптируемым объектом. В этом случае может даже осуществляться преобразование одного интерфейса в другой без привязки к конкретной реализации.
Но встречаются ситуации, когда требуется применение адаптера класса. Например, необходимость доступа к protected методам. В другом случае может потребоваться использовать Адаптер и вместо адаптируемого объекта.
Реализация Адаптера объекта
- создаем класс ITarget или являться наследником от класса Target с нужным интерфейсом;
- в его закрытом поле _adaptee размещаем экземпляр адаптируемого объекта;
- реализуем интерфейс ITarget
Реализация Адаптера класса
- создаем класс , который будет реализовывать требуемый интерфейс ITarget;
- шаблон позволяет использовать наследование от класса Target , но в C# этот вариант не может быть реализован. Причина – запрет на множественное наследование.
- добавлением классу наследование от адаптируемого класса;
- реализуем интерфейс ITarget , в методах которого вызываем нужные методы адаптируемого объекта;
- клиент использует экземпляр класса и получает требуемую функциональность.
Примеры реализации
1. Адаптер объекта
Задача: в приложении необходимо воспроизводить звуковые сигналы для оповещения пользователя, которые в данный момент хранятся в формате.wav.
Интерфейс IAudioPlayer содержит описание функций самого простого медиаплеера, осуществляющего загрузку и воспроизведение аудиофайла.
///
При реализации обратим внимание, что.NET уже содержит класс SoundPlayer , предоставляющий подобные возможности. Однако данный класс не поддерживает заданный интерфейс. Поэтому воспользуемся шаблоном Адаптер:
///
Код очень простой. Можно отметить только использование Отложенной инициализации (с помощью generic-класса Lazy ) для адаптируемого класса. Это сделано на случай, если не будет загружено или воспроизведено ни одного аудиофайла.
Теперь возможно использовать возможности SoundPlayer в разрабатываемом приложении:
Private IAudioPlayer _player = new SoundPlayerAdapter(); public void NotifyUser(int messageCode) { string wavFile = string.Empty; /* Skipped */ // play the audio file if (!string.IsNullOrEmpty(wavFile)) { this._player.Load(wavFile); this._player.Play(); } }
Может возникнуть вопрос: почему сразу не использовать класс SoundPlayer ? В отличии от явного использования указанного класса, данный подход обеспечил независимость кода от конкретной реализации медиаплеера. Например, в дальнейшем можно легко заменить SoundPlayerAdapter на другой класс для поддержки файлов другого формата.
2. Адаптер класса
Давайте рассмотрим решение той же задачи с помощью адаптера класса.
В этот раз необходимо наследовать SoundPlayerAdapter не только от интерфейса IAudioPlayer , но и от класса SoundPlayer . В результате получаем готовый метод Play() , а вот метод Load() придется определить самостоятельно.
///
Что изменилось по сравнению с первым вариантом?
Исчезла отложенная инициализация адаптируемого объекта, которая в первом варианте была "из коробки" и прозрачна для клиентского кода.
Код реализации стал короче, т.к. пришлось создавать только недостающие методы. Возможна ситуация, когда класс Адаптера не содержал бы никакого кода. Например:
///
Кроме того, экземпляр класса SoundPlayerAdapter теперь предоставляет полный перечень свойств и методов, унаследованных от адаптируемого объекта . Он может быть использован вместо экземпляра SoundPlayer при необходимости. Но стоит помнить, что в этом случае усиливается связь между адаптируемым объектом и кодом приложения. И это самый большой минус данного варианта.
Назначение
Адаптер (англ. 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
Задача преобразования интерфейсов может оказаться непростой в случае, если клиентские вызовы и (или) передаваемые параметры не имеют функционального соответствия в адаптируемом объекте.
