问题描述
这解释了我所指的“桥接”模式：https://refactoring.guru/design-patterns/bridge
这是上面帖子中的一个场景：
假设您有一个带有一对子类的几何 Shape 类：Circle 和 Square。您希望扩展此类层次结构以合并颜色，因此您计划创建红色和蓝色形状子类。但是，由于您已经有两个子类，因此您需要创建四个类组合，例如 BlueCircle 和 RedSquare。
这个场景存在的问题：
向层次结构添加新的形状类型和颜色将使层次结构呈指数级增长。例如，要添加一个三角形，您需要引入两个子类，每种颜色一个。之后，添加新颜色需要创建三个子类，每个形状类型一个。我们走得越远，情况就变得越糟。
为了避免这个问题，我们像这样实现桥接模式：
将与颜色相关的代码提取到它自己的具有两个子类的类中：红色和蓝色。然后，Shape 类获取一个指向颜色对象之一的引用字段。现在形状可以将任何与颜色相关的工作委托给链接的颜色对象。该引用将充当 Shape 和 Color 类之间的桥梁。从现在开始，添加新颜色不需要更改形状层次结构，反之亦然。
我了解此实施的方式和原因。
但是如果我们需要第三层级呢，例如BorderStyle（其中边框样式可以是 Straight、Wavy 或 ZigZag？）
我想我们可以为 BorderStyle 实现第二个实现器类，并将它传递给 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 个以上的层次结构/属性（在想也许是装饰器模式？）
如果我遗漏了任何相关信息，我深表歉意——这种设计模式对我来说是全新的。感谢您的帮助！
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）