桥接模式是否将抽象与实现分离？
我从不同的文章中学习了Bridge模式，并根据我的理解实现了它。 令我困惑的一件事是桥模式说
BridgePattern将抽象与其实现分离，以便两者可以独立变化
这句话是什么意思？ 实现是在单独的jar中吗？
什么是独立声明的含义？
考虑提供的journaldev文章，详细说明答案。
任何帮助是极大的赞赏。
BridgePattern将抽象与其实现分离 。
抽象和实现可以独立变化，因为具体类不直接实现抽象 （接口）
注意： 两个正交的类层次结构 （ 抽象层次结构和实现层次结构 ）使用组合（而不是inheritance）进行链接。此组合有助于两个层次结构独立变化。
实现从未引用抽象。 抽象包含实现接口作为成员（通过组合）。
回到你关于journaldev文章中的示例代码的问题：
形状是抽象
三角形是RedefinedAbstraction
颜色是执行者
RedColor是ConcreteImplementor
具体的Shape对象： Triangle扩展Shape但不实现Color接口。
public class Triangle extends Shape{ } RedColor和GreenColor实际上实现了Color接口。
Concrete Shape对象（ Triangle ）独立于实现抽象（即Color接口）。
Shape tri = new Triangle(new RedColor());
这里Triangle包含一个具体的Color对象（ Composition ）。 如果颜色抽象（界面）发生变化， RedColor和GreenColor负责实现Color接口的抽象。
像Triangle这样的形状不受Color接口合约更改的影响。 因此， Color界面可以独立变化。 这是可能的，因为Shape持有使用Composition而不是实现的契约。
综上所述，
- 桥是一种结构模式
- 抽象和实现不受编译时的约束
- 抽象和实施 – 两者都可以在客户端没有影响的情况下变化
在以下情况下使用Bridge模式：
- 您想要实现的运行时绑定，
- 您从耦合接口和众多实现中获得了大量类，
- 您想要在多个对象之间共享实现，
- 您需要映射正交类层次结构。
有用的链接：
tutorialspoint artice
dzone文章
oodesign文章
源文章
相关文章：
你什么时候使用Bridge Pattern？ 它与适配器模式有何不同？
这个语句只是意味着你可以在运行时切换到抽象点的实现者，一切都应该工作（比如在Strategy Pattern中;但在Strategy Pattern中，只有策略是抽象的）。 它也可以被理解为将两个类分开，这样它们就不必仅仅知道彼此的接口了解彼此。
对我来说，Bridge并不是GOF圣经中最重要的DP，因为它主要是战略的衍生物。 由于一些其他模式没有很好地老化（工厂方法？），它意味着更多的inheritance与抽象类保持行为比其他模式，因此不太普遍适用。
它主要是战略做大工作，但战略的一个主要问题是战略往往需要有关其背景的知识。
在某些语言中，这会导致策略被声明为上下文的朋友，或者在Java中定义为内部类的策略。
这意味着上下文通常最终会得到各种具体策略存在的知识。 您可以通过使用setStrategy（）函数来避免这种情况，但由于效率原因（您希望直接操作上下文的数据结构），从具体策略到上下文的反向依赖通常会存活下来。
这个问题是由Bridge解决的，因为策略的上下文现在是抽象的，但仍然是一个先验的类，因为它至少具有策略的代码。 它通常应该定义一个足以使用具体策略的访问API，可能带有漏洞，即抽象方法。 你在AbstractStragey上的操作的签名中放置了一个AbstractContext，你很好。
所以在我看来，Bridge通过使Context具有足够的策略来完成策略，但仍然足够抽象，可以通过具体策略进行正交优化（在实现具体策略的上下文的抽象API时具有反馈效果）实际上使用）。
一种更简单的看桥方式就是说，AbstractStrategy操作应该始终将抽象作为参数，而不是真正了解它们的上下文。
更准确地回答OP问题：
这句话是什么意思？ 实现是在单独的jar中吗？
是的，的确，通常你可以在一个包“base”中定义抽象和实现者（tey可以是接口）。 具体的实现者可以各自驻留在一个包“implXX”中。 具体上下文可以驻留在单独的包“contXX”中。 依赖图中没有循环，每个人都依赖于base，新的“contXX”和“implXX”可以独立定义（它们之间根本没有依赖），因此OP中的粗体语句。
什么是独立声明的含义？
想想eclipse中的编辑器插件; 它必须处理按钮和点击的操作（如策略），但策略需要做的实际操作是对编辑器状态本身起作用（例如“突出显示文本”）。 您可以用抽象的方式定义编辑器拥有的内容，包括它具有用于隐藏和按键的Handler以及突出显示和导航function，甚至可以通过具体编辑器（闪存而不是突出显示）覆盖这些function。 这是一座桥梁，您可以独立定义新的编辑器和新的处理程序。
通过一些dependency injection（例如Google guice）或一些手动工厂代码或组件方向来从外部干净地设置策略，您可以获得应用程序各个部分的非常低的耦合。
考虑提供的journaldev文章，详细说明答案。
老实说，我认为这不是DP的最佳应用，因为Color实现似乎并不关心它们的上下文。 你应该在这里使用一个Decorator，因为Color是Shape的一个独立问题。
看看这些幻灯片上的装饰解决方案（部分用法语，对不起）。 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。
在那个例子中，如果“updateInertie”是Forme的成员，我们将需要Bridge，这听起来并不荒谬。 Bridge再次成为其他模式的组合。