应该如何为两个以上的层次结构实现“桥”设计模式？

Question

这解释了我所指的“桥”模式：https://refactoring.guru/design-patterns/bridge

这是上面帖子中的一个场景：

假设您有一个带有一对子类的几何 Shape 类：Circle 和 Square。您希望扩展此类层次结构以合并颜色，因此您计划创建红色和蓝色形状子类。但是，由于您已经有两个子类，因此您需要创建四个类组合，例如 BlueCircle 和 RedSquare。

这个场景提出的问题：

向层次结构添加新的形状类型和颜色会使层次结构呈指数增长。例如，要添加一个三角形，您需要引入两个子类，每种颜色一个。之后，添加新颜色需要创建三个子类，每个子类对应一个形状类型。我们走得越远，情况就越糟。

为了避免这个问题，我们这样实现桥接模式：

将与颜色相关的代码提取到具有两个子类的自己的类中：Red 和 Blue。然后 Shape 类获得一个指向颜色对象之一的引用字段。现在，形状可以将任何与颜色相关的工作委托给链接的颜色对象。该引用将充当 Shape 和 Color 类之间的桥梁。从现在开始，添加新颜色将不需要更改形状层次结构，反之亦然。

我了解此实施的方式和原因。

但是如果我们需要第三个层次结构，例如BorderStyle（其中边框样式可以是Straight、Wavy 或ZigZag？）

我想我们可以为 BorderStyle 实现第二个 Implementor 类，并将其传递给 Shape 构造函数，如下所示：

# Blue inherits from the Color class (Implementation)
color_implementation = Blue.new()

# Wavy inherits from the BorderStyle class (Implementation)
border_style_implementation = Wavy.new()

# Triangle inherits from the Shape class, which we consider our Abstraction
shape = Triangle.new(color_implementation, border_style_implementation)

shape.draw() # prints "I'm a Blue Triangle with Wavy borders!"

所以我的问题是：

1.) 上面的例子“有效吗？” （也许它是工作代码，但它会以某种方式引入技术债务吗？）

1a.) 如果这不起作用，为什么不呢？

1b.) 如果这确实“有效”，它是否正确应用了桥接模式？是否有更好的设计模式可用于管理超过 2 个层次结构/属性（是否考虑过装饰器模式？）

如果我遗漏了任何相关信息，我深表歉意——这种设计模式对我来说是全新的。感谢您的帮助！

Answer 1

是的，这行得通。将两个 Bridge 关系添加到一个抽象中没有任何问题（除了兼顾三个不同层次结构的复杂性）。

Decorator 肯定不会为此目的工作，因为它维护一个单一的层次结构，这是客户端已知的。客户端不知道桥中的 Implementor 层次结构（或本例中的层次结构）。

我会澄清链接的文章，它说，

您想扩展此 [shape] 类层次结构以合并颜色

我认为这过于简单化了 Bridge 的动机。 Implementors 不仅仅是您选择添加到 Abstraction 以增强它的一些属性。您的Abstraction 需要Implementor 才能正常运行。 Abstraction 的子类中的方法实现除了调用Implementor 的方法外，一般几乎没有什么作用。

Abstraction 代表您的高级业务 API，而 Implementor 代表较低级别的原始 API。它们都是抽象，但处于不同的层次。我认为形状和颜色的例子不能充分传达这一点，因为形状和颜色看起来像是同一层次的抽象。客户会知道形状和颜色，两者都不会严格依赖于另一个。

因此，应用桥接器的原因比给定示例更具体，但您当然可以有两个。