В чем разница между шаблонами моста и адаптера?
Разница между мостом и шаблоном адаптера
Ответ 1
"Адаптер заставляет вещи работать после того, как они спроектированы; Bridge заставляет их работать раньше, чем они будут. [GoF, p219]"
По сути, шаблон Adapter полезен, когда у вас есть существующий код, будь то сторонний или внутренний, но не зависящий от вас или не изменяемый другим образом, чтобы полностью соответствовать интерфейсу, который вам необходим. Например, у нас есть SuperWeaponsArray, который может управлять множеством устройств конца света.
public class SuperWeaponsArray {
/*...*/
public void destroyWorld() {
for (Weapon w : armedWeapons) {
w.fire();
}
}
}
Отлично. За исключением того, что мы понимаем, что в нашем арсенале есть ядерное устройство, которое значительно предшествует переходу на интерфейс с оружием. Но нам бы очень хотелось, чтобы это работало здесь... так что же нам делать... вклинивать это!
NukeWeaponsAdaptor - основан на нашем классе Nuke, но экспортирует интерфейс оружия. Сладкий, теперь мы можем разрушить мир. Это кажется чем-то вроде клуджа, но это заставляет вещи работать.
Паттерн Bridge - это то, что вы реализуете заранее - если вы знаете, что у вас есть две ортогональные иерархии, он предоставляет способ разъединить интерфейс и реализацию таким образом, что вы не получите безумное количество классов. Допустим, у вас есть:
MemoryMappedFile и DirectReadFile типы файловых объектов. Допустим, вы хотите иметь возможность читать файлы из разных источников (возможно, Linux или Windows и т.д.). Bridge поможет вам избежать:
MemoryMappedWindowsFile MemoryMappedLinuxFile DirectReadWindowsFile DirectReadLinuxFile
Ответ 2
http://en.wikipedia.org/wiki/Adapter_pattern
Шаблон адаптера больше связан с тем, чтобы ваш существующий код работал с более новой системой или интерфейсом.
Если у вас есть набор API-интерфейсов веб-сервисов компании, которые вы хотели бы предложить другому существующему интерфейсу расширяемости, вы можете подумать о написании набора адаптеров для этого. Обратите внимание, что есть серая область, и это больше о том, как вы технически определяете шаблон, поскольку другие шаблоны, подобные фасаду, похожи.
http://en.wikipedia.org/wiki/Bridge_pattern
Шаблон Bridge позволит вам иметь альтернативные варианты реализации алгоритма или системы.
Хотя это не классический пример шаблона Bridge, представьте себе, если у вас было несколько реализаций хранилища данных: один из них эффективен в пространстве, другой эффективен в сырой производительности... и у вас есть бизнес-пример для размещения как в вашем приложения или рамки.
С точки зрения вашего вопроса, "где я могу использовать шаблон", ответ есть, где это имеет смысл для вашего проекта! Возможно, подумайте о том, чтобы предложить разъяснение, чтобы вести дискуссию о том, где вы считаете, что вам нужно использовать тот или иной.
Ответ 3
Этот пост существует довольно давно. Однако важно понимать, что фасад несколько похож на адаптер, но это не совсем то же самое. Адаптер "адаптирует" существующий класс к обычно несовместимому классу клиентов. Скажем, у вас есть старая система документооборота, которую приложение использует в качестве клиента. Возможно, ваша компания заменит систему документооборота новой "несовместимой" (с точки зрения интерфейсов). В большинстве случаев вы можете использовать шаблон адаптера и писать код, который фактически вызывает новые интерфейсы движка рабочего процесса. Мост обычно используется по-другому. Если у вас есть система, которая должна работать с разными файловыми системами (например, с локальным диском, NFS и т.д.), Вы можете использовать шаблон моста и создать один уровень абстракции для работы со всеми файловыми системами. Это будет в основном простой пример использования шаблона моста. Фасад и адаптер имеют общие свойства, но фасады обычно используются для упрощения существующего интерфейса/класса. В первые дни EJB не было локальных звонков для EJB. Разработчики всегда получали заглушку, сужали ее и называли ее "псевдо-удаленно". Это часто приводило к проблемам с производительностью (особенно при вызове по проводам). Опытные разработчики использовали бы шаблон фасада для обеспечения очень грубоватого интерфейса для клиента. Этот фасад затем, в свою очередь, будет выполнять множественные вызовы на различные более мелкозернистые методы. В целом это значительно сократило количество требуемых вызовов методов и повышенную производительность.
Ответ 4
Adapter:
- Это структурный шаблон
- Полезно работать с двумя несовместимыми интерфейсами
Диаграмма UML: из dofactory статья:
Target: определяет специфический для домена интерфейс, который использует Клиент.
Адаптер: адаптирует интерфейс Adaptee к интерфейсу Target.
Adaptee: определяет существующий интерфейс, который нуждается в адаптации.
Клиент: взаимодействует с объектами, соответствующими интерфейсу Target.
Пример:
Квадрат и Прямоугольник - это две разные формы, и для каждой области() каждой из них требуются разные методы. Но все же Square работает над интерфейсом Rectangle с преобразованием некоторых свойств.
public class AdapterDemo{
public static void main(String args[]){
SquareArea s = new SquareArea(4);
System.out.println("Square area :"+s.getArea());
}
}
class RectangleArea {
public int getArea(int length, int width){
return length * width;
}
}
class SquareArea extends RectangleArea {
int length;
public SquareArea(int length){
this.length = length;
}
public int getArea(){
return getArea(length,length);
}
}
Мост:
- Это структурный шаблон
- он отделяет абстракцию от ее реализации, и оба могут варьироваться независимо.
- Это возможно, потому что композиция была использована вместо наследования
EDIT: (согласно предложению @quasoft)
У вас есть четыре компонента в этом шаблоне.
-
Абстракция: он определяет интерфейс
-
RefinedAbstraction: он реализует абстракцию:
-
Исполнитель: он определяет интерфейс для реализации
-
ConcreteImplementor: он реализует интерфейс разработчика.
Фрагмент кода:
Gear gear = new ManualGear();
Vehicle vehicle = new Car(gear);
vehicle.addGear();
gear = new AutoGear();
vehicle = new Car(gear);
vehicle.addGear();
Похожие сообщения:
Когда вы используете шаблон моста? Как это отличается от шаблона адаптера?
Основные отличия: от sourcemaking статья
- Адаптер позволяет работать после того, как они разработаны; Мост заставляет их работать до того, как они будут.
- Мост разработан заранее, чтобы абстракция и реализация менялись независимо. Адаптер модернизирован для совместной работы не связанных между собой классов.
Ответ 5
Предположим, что у вас есть абстрактный класс Shape с функциональностью рисования (общий/абстрактный) и круг, который реализует форму. Мост-шаблон просто является двухсторонним абстракционным подходом к развязке реализации (рисунок в круге) и универсальной/абстрактной функциональности (рисунок в классе Shape).
Что это значит? На первый взгляд это похоже на то, что вы уже делаете (путем инверсии зависимостей). Поэтому не стоит беспокоиться о том, чтобы иметь меньшую или более модульную базу кода. Но это немного более глубокая философия.
С моей точки зрения, необходимость использования шаблона может возникнуть, когда мне нужно добавить новые классы, которые тесно связаны с текущей системой (например, RedCircle или GreenCircle), и которые они отличаются только одной функциональностью (например, цветом). И мне понадобится шаблон моста, особенно если существующие системные классы (круг или форма) должны быть часто изменены, и вы не хотите, чтобы новые добавленные классы были затронуты этими изменениями. Итак, почему универсальная функция рисования абстрагируется от нового интерфейса, так что вы можете изменять поведение рисунка независимо от формы или круга.
Ответ 6
Мост улучшен Адаптер. Мост включает адаптер и добавляет дополнительную гибкость. Вот как элементы Ravindra отвечают на карту между шаблонами:
Adapter | Bridge
-----------|---------------
Target | Abstraction
-----------|---------------
| RefinedAbstraction
|
| This element is Bridge specific. If there is a group of
| implementations that share the same logic, the logic can be placed here.
| For example, all cars split into two large groups: manual and auto.
| So, there will be two RefinedAbstraction classes.
-----------|---------------
Adapter | Implementor
-----------|---------------
Adaptee | ConcreteImplementor