桥接模式:是将抽象部分与它的实现部分分离,使他们都可以独立的变化。
想象一下开关和电器分别被抽象成两个不同的继承类。
优点:
- 分离抽象和实现部分。桥接模式使用“对象间的关联关系”解耦了抽象和实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度来变化。即抽象和实现不再在同一个继承层次结构中,而是“子类化”它们,使它们各自都具有自己的子类,以便可以进行任意组合,从而获得多维度的组合对象。
- 在很多情况下,桥接模式可以取代多层继承方案。多层继承违背了“单一职责原则”,复用性较差,且类的个数非常多。所以相比起来,桥接模式更好,它极大地减少了子类的个数。
- 提高了系统的可扩展性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统,符合“开闭原则”。
缺点:
-
增加了系统的理解与设计难度,由于关联关系建立在抽象层,要求开发者一开始就针对抽象层进行设计与编程。
-
需要能正确识别出系统中两个独立变化的维度,因此使用范围具有一定的局限性,如何正确识别两个独立维度也需要一定的经验积累。
适用场景:
-
如果一个系统需要在抽象化和具体化之间增加更多的灵活性,避免在两个层次之间建立静态的继承关系,通过桥接模式可以使它们在抽象层建立一个关联关系。
-
“抽象部分”和“实现部分”可以以继承的方式独立扩展而互不影响,在程序运行时,可以动态地将一个抽象化子类的对象和一个实现化子类的对象进行组合,即系统需要对抽象化角色和实现化角色进行动态耦合。
-
一个系统存在多个(≥ 2)独立变化的维度,且这多个维度都需要独立进行扩展。
-
对于那些不希望使用继承或因为多层继承导致系统类的个数急剧增加的系统,桥接模式尤为适用。
案例分析:
电器是生活中必不可少的东西,几乎每家每户都有,例如:电视、风扇、电灯 ...... 虽然类型众多,但无论什么电器,都是由开关控制的。而开关也有很多种,例如:拉链式开关、两位开关、调光开关 ......
对于开关和电器来说,不管任何时候,都可以在不触及另一方的情况下进行更换。比如,可以在不更换开关的情况下换掉灯泡(或风扇),也可以在不接触灯泡(或风扇)的情况下更换掉开关,甚至可以在不接触开关的情况下将灯泡和风扇互换。
这看起来很自然,当然也应该是这样!当不同的事物联系到一起时,它们应该在一个可以变更或者替换的系统中,以便不相互影响或者使影响尽可能的小,这样才能更方便、更低成本地去管理系统。试想一下,如果要更换房间里的一个灯泡,还必须把开关也换了,你会考虑使用这样的系统吗。
电器类抽象:
开关类抽象:
使用: