桥梁设计模式中抽象的含义
Meaning of abstraction in bridge design pattern
我对如何解释 java 中的桥梁设计模式感到困惑。根据 GoF 的定义：
The bridge pattern is to decouple an abstraction from its implementation so that the two can vary independently.
但是，我认为我们进行抽象（使用抽象 classes 和接口）将实现与其余代码分离（因为我们只是声明接口或抽象 class es 而不是实现 class)。现在，由于桥接模式，我认为我对抽象的理解是错误的。
什么是抽象以及它如何与实现分离桥接模式?
Abstraction 在这种情况下不是在抽象的意义上使用 类 等。抽象更多地用于 higher-level 某事的想法而实现是这个想法的具体实现。
举个例子，假设您正在建造玩具屋。房子的一般概念是有墙、门、windows 和屋顶的东西。那就是抽象。
但是您可以用不同的 materials/construction 套装（乐高或得宝、纸、木头、硬纸板）建造房屋。那将是实施。在每个版本中，您都需要了解如何建造墙壁、门、windows 和屋顶。
所以你基本上将相同的房子抽象概念与不同的实现结合起来。这就是我理解的桥梁模式的本质。
I thought that we do abstractions (use of abstract classes and
interfaces) to decouple the implementation from the rest of the code
你的理解是正确的。
您在极端情况下使用桥接 ，在这种情况下，您不仅有一个而且有两个（或更多）抽象，您不想混合在一起。
GOF 模式很好地说明了这一点。
工具包的 window 依赖于两个抽象：
- window 组件（图标、瞬态、全尺寸等...）
- window 与 OS implementation/features 的关系。
如果您定义一个接口：Window，您会将两个抽象耦合到同一个接口中，Window 实现将因此耦合它们。
如果您定义两个接口：Window（作为 model/functional 概念）和 WindowImp（作为 OS 实现）和两个不同的层次结构：您将抽象。
What exactly is abstraction and how is it decoupled from
implementation in the bridge pattern?
我假设您熟悉许多桥梁图案文章中使用的形状和颜色示例。例如。 here（如果你不熟悉，最好通过这个 link）
形状和颜色基本上是出于明天您可能需要紫色矩形或带渐变的十二边形的需要而创建的抽象概念！文章中，Shape有一个Color（Abstraction依赖于一个抽象）。 如果 Shape 有红色，就好像抽象取决于实现（它将耦合） 并且每次需要时都必须创建一个新的 class不同的颜色。
我知道我的回答不够，但我希望这是理解桥接模式的最后一块拼图。
我对如何解释 java 中的桥梁设计模式感到困惑。根据 GoF 的定义：
The bridge pattern is to decouple an abstraction from its implementation so that the two can vary independently.
但是，我认为我们进行抽象（使用抽象 classes 和接口）将实现与其余代码分离（因为我们只是声明接口或抽象 class es 而不是实现 class)。现在，由于桥接模式，我认为我对抽象的理解是错误的。
什么是抽象以及它如何与实现分离桥接模式?
Abstraction 在这种情况下不是在抽象的意义上使用 类 等。抽象更多地用于 higher-level 某事的想法而实现是这个想法的具体实现。
举个例子，假设您正在建造玩具屋。房子的一般概念是有墙、门、windows 和屋顶的东西。那就是抽象。
但是您可以用不同的 materials/construction 套装（乐高或得宝、纸、木头、硬纸板）建造房屋。那将是实施。在每个版本中，您都需要了解如何建造墙壁、门、windows 和屋顶。
所以你基本上将相同的房子抽象概念与不同的实现结合起来。这就是我理解的桥梁模式的本质。
I thought that we do abstractions (use of abstract classes and interfaces) to decouple the implementation from the rest of the code
你的理解是正确的。
您在极端情况下使用桥接 ，在这种情况下，您不仅有一个而且有两个（或更多）抽象，您不想混合在一起。
GOF 模式很好地说明了这一点。
工具包的 window 依赖于两个抽象：
- window 组件（图标、瞬态、全尺寸等...）
- window 与 OS implementation/features 的关系。
如果您定义一个接口：Window，您会将两个抽象耦合到同一个接口中，Window 实现将因此耦合它们。
如果您定义两个接口：Window（作为 model/functional 概念）和 WindowImp（作为 OS 实现）和两个不同的层次结构：您将抽象。
What exactly is abstraction and how is it decoupled from implementation in the bridge pattern?
我假设您熟悉许多桥梁图案文章中使用的形状和颜色示例。例如。 here（如果你不熟悉，最好通过这个 link）
形状和颜色基本上是出于明天您可能需要紫色矩形或带渐变的十二边形的需要而创建的抽象概念！文章中，Shape有一个Color（Abstraction依赖于一个抽象）。 如果 Shape 有红色，就好像抽象取决于实现（它将耦合） 并且每次需要时都必须创建一个新的 class不同的颜色。
我知道我的回答不够，但我希望这是理解桥接模式的最后一块拼图。