Выделяет ли шаблон моста абстракцию от реализации?

Я изучил шаблон моста из разных статей, и я реализовал его в соответствии с моим пониманием. Одна вещь, которая меня путает, - это шаблон моста, который говорит

BridgePattern отделяет абстракцию от ее реализации, так что они могут варьироваться независимо друг от друга.

что означает это утверждение? Реализация находится в отдельной банке?

что означает независимо друг от друга утверждение?

учитывая предоставленную journaldev статью, напишите ответ.

Любая помощь очень ценится.

Ответ 1

BridgePattern отделяет абстракцию от своей реализации.

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

Диаграмма UML из Википедии

Ключевое примечание: Две иерархии ортогональных классов (иерархия Абстракция y и иерархия реализации) связаны с использованием композиции (а не наследования). Эта композиция позволяет обеими иерархиями меняться независимо друг от друга.

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

Возвращаясь к вашему вопросу относительно кода примера в journaldev:

Форма Абстракция

Треугольник ПереопределеннаяАбстракция

Цвет Исполнитель

RedColor ConcreteImplementor

Конкретный объект Shape: Triangle расширяет форму, но не реализует интерфейс Color.

public class Triangle extends Shape{
}

RedColor и GreenColor фактически реализуют интерфейс Color.

Объект Concrete Shape (Треугольник) не зависит от реализации абстракции (т.е. интерфейса цвета).

Shape tri = new Triangle(new RedColor());

Здесь Треугольник содержит конкретный объект Цвет (Состав). Если в абстракции Цвет есть изменение (интерфейс), RedColor и GreenColor отвечают за реализацию абстракции Цвет интерфейс.

На фигуры, подобные треугольнику, не влияют изменения контракта на интерфейс Color. Таким образом, интерфейс Color может меняться независимо. Это возможно, потому что Shape заключает контракт, который использует Композиция, а не реализация.

В резюме

  • Мост - структурный шаблон.
  • Абстракция и реализация не связаны во время компиляции
  • Абстракция и реализация - оба могут варьироваться без воздействия на клиента

Используйте шаблон Bridge, если:

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

Полезные ссылки:

tutorialspoint artice

dzone статья

oodesign статья

sourcemaking статья

Похожие сообщения:

Когда вы используете шаблон моста? Как это отличается от шаблона адаптера?

Ответ 2

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

Ответ 3

Для меня мост на самом деле не самый главный DP в Библии GOF, так как он в основном является производным от стратегии. Как и некоторые другие шаблоны, которые не так хорошо выдерживают (метод factory?), Это подразумевает большее наследование с абстрактными классами, удерживающими поведение, чем другие шаблоны, следовательно, в меньшей степени применимо.

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

В некоторых языках это приводит к объявлению стратегий друг друга контекста или стратегий, определяемых как внутренние классы в Java.

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

Эта проблема решается Мостом, поскольку контекст Стратегии теперь абстрактный, но все же класс априори, поскольку у него есть хотя бы код для Стратегии. Он должен обычно определять API доступа, достаточный для конкретных стратегий, с которыми можно работать, возможно, с помощью дыр, например абстрактных методов. Вы помещаете появление AbstractContext в подпись операций на AbstractStragey, и вы хороши.

Итак, с моей точки зрения, Bridge завершает Стратегию, делая Контекст достаточно конкретным, чтобы стратегии работали, но все же достаточно абстрактны, чтобы его можно было ортогонально уточнить w.r.t. (с эффектами обратной связи при реализации абстрактного API контекста, который фактически использует конкретные стратегии).

Простейший способ увидеть мост - сказать, что операции AbstractStrategy всегда должны брать абстракции как параметры, а не реально знать их контекст.

Чтобы более точно ответить на вопрос ОП:

что означает это утверждение? Реализация находится в отдельной банке?

Да, действительно, как правило, вы могли бы определить Абстракцию и Реализатор в пакете "base" (tey могли бы быть интерфейсы). Конкретные исполнители могут каждый из них находиться в пакете "implXX". Конкретный контекст может находиться в отдельных пакетах "contXX". На графике зависимостей нет циклов, все зависят от базы, новые "contXX" и "implXX" могут быть определены независимо (между ними нет взаимозависимостей), таким образом, жирный оператор в OP.

что означает независимо друг от друга утверждение?

Подумайте о плагине редактора в eclipse; он должен обрабатывать действия на кнопках и кликах (например, в стратегии), но фактическое действие, которое должна выполнить стратегия, заключается в самом состоянии редактора (например, "выделить текст" ). Вы определяете, что редактор обладает абстрактным образом, в том числе тот факт, что он имеет Handler для кликов и нажатий клавиш, а также функции подсветки и навигации, даже они могут быть перечеркнуты конкретными редакторами (flash вместо выделения). Это мост, вы можете самостоятельно определять новые редакторы и новый обработчик.

При использовании некоторой инъекции зависимостей (например, Google) или какого-либо ручного кода factory или ориентации компонента для чистого setStrategy извне вы получаете очень низкое соединение различных частей приложения.

учитывая предоставленную статью journaldev, уточните ответ.

Честно говоря, я считаю, что это не лучшее приложение DP, поскольку реализации Color не очень заботятся об их контексте. Вы должны использовать Decorator здесь, так как Color является независимой задачей от Shape.

Посмотрите на эти слайды для решения с Decorator (частично на французском языке, извините). https://www-licence.ufr-info-p6.jussieu.fr/lmd/licence/2015/ue/3I002-2016fev/cours/cours-9.pdf (слайды 16-18) на основе приведенного здесь примера: https://www-licence.ufr-info-p6.jussieu.fr/lmd/licence/2015/ue/3I002-2016fev/cours/cours-4.pdf слайды от 10 до 15.

В этом примере нам понадобится Bridge, если "updateInertie" был членом Forme, что не звучит нелепо. Снова мост проявляется больше как комбинация других моделей.