当人们开始学习设计模式时,他们经常把注意力放在模式提供的解决方案上。这看起来似乎很合理,因为设计模式被广为宣传的一点就是能够为实际问题提供优秀的解决方案。
但是,这从方向上来说就是错误的。在尝试将某个解决方案应用到一个问题之前,应该先理解问题。这种只是寻找在何处应用模式的方法,只能告诉你要做什么,但是不能告诉你什么时候或者为什么使用。
将注意力放在模式的上下文——模式试图解决的问题上,要有用的多。这能够使我们知道什么时候或者为什么使用模式。这与 Alexander 的模式理念也更相符,“每个模式都描述了一个在我们的环境中会不断重复出现的问题,并进而叙述了这个问题解决方案的要素......”
当存在一个抽象有不同的实现时,Bridge 模式最为有用,它可以使抽象和实现互相独立地进行变化。这里的实现指的是抽象类及其派生类用来实现自己的对象。
尽可能地尝试使用聚集,其意图是能够在互相独立的类中包含变化,从而允许未来发生变化,而不影响原有的代码。实现这一目的的一种方式是:将所有的变化都分别放在自己的抽象类中,然后观察这些抽象类之间的关系。
Bridge 模式:关键特征
意图:将一组实现与另一组使用它们的对象分离。
问题:一个对象类的派生类必须使用多个实现,但不能出现类数量爆炸性增加。
解决方案:为所有实现定义一个接口,供抽象类的所有派生类所用。
参与者与协作者:Abstraction 为要实现的对象定义接口,Implementor 为具体的实现类定义接口。Abstraction 的派生类使用 Implementor 的派生类,却无需知道自己具体使用哪一个 ConcreteImplementor。
效果:实现与使用实现的对象解耦,提供了可扩展性,客户对象无需操心实现问题。
实现:1、将实现封装在抽象类中; 2、在要实现的抽象的基类中包含一个实现的句柄。
遵循“一条规则,实现一次”的策略有助于重构。
对应变化的基本策略:
1、找到变化并封装之;
2、优先使用对象聚集而不是类继承。
“找到变化”在了解问题域的过程中永远是一个重要的步骤。
Bridge 模式中使用的面向对象原则的总结:
1、对象对自己负责;
2、抽象类;
3、通过抽象类进行封装;
4、一条规则,实现一次;
5、可测试性。