1700476084
1700476085
}
1700476086
1700476087
}
1700476088
1700476089
桥梁模式是一个非常简单的模式，它只是使用了类间的聚合关系、继承、覆写等常用功能，但是它却提供了一个非常清晰、稳定的架构。
1700476090
1700476091
1700476092
1700476093
1700476095
设计模式之禅 29.3 桥梁模式的应用
1700476096
1700476097
29.3.1 桥梁模式的优点
1700476098
1700476099
❑抽象和实现分离
1700476100
1700476101
这也是桥梁模式的主要特占，它完全是为了解决继承的缺点而提出的设计模式。在该模式下，实现可以不受抽象的约束，不用再绑定在一个固定的抽象层次上。
1700476102
1700476103
❑优秀的扩充能力
1700476104
1700476105
看看我们的例子，想增加实现？没问题！想增加抽象，也没有问题！只要对外暴露的接口层允许这样的变化，我们已经把变化的可能性减到最小。
1700476106
1700476107
❑实现细节对客户透明
1700476108
1700476109
客户不用关心细节的实现，它已经由抽象层通过聚合关系完成了封装。
1700476110
1700476111
1700476112
1700476113
1700476114
设计模式之禅 29.3.2 桥梁模式的使用场景
1700476115
1700476116
❑不希望或不适用使用继承的场景
1700476117
1700476118
例如继承层次过渡、无法更细化设计颗粒等场景，需要考虑使用桥梁模式。
1700476119
1700476120
❑接口或抽象类不稳定的场景
1700476121
1700476122
明知道接口不稳定还想通过实现或继承来实现业务需求，那是得不偿失的，也是比较失败的做法。
1700476123
1700476124
❑重用性要求较高的场景
1700476125
1700476126
设计的颗粒度越细，则被重用的可能性就越大，而采用继承则受父类的限制，不可能出现太细的颗粒度。
1700476127
1700476128
1700476129
1700476130
1700476131
设计模式之禅 29.3.3 桥梁模式的注意事项
1700476132
1700476133
桥梁模式是非常简单的，使用该模式时主要考虑如何拆分抽象和实现，并不是一涉及继承就要考虑使用该模式，那还要继承干什么呢？桥梁模式的意图还是对变化的封装，尽量把可能变化的因素封装到最细、最小的逻辑单元中，避免风险扩散。因此读者在进行系统设计时，发现类的继承有N层时，可以考虑使用桥梁模式。
[
上一页 ]
[ :1.700476084e+09 ]
[
下一页 ]