0
点赞
收藏
分享

微信扫一扫

设计模式利剑23--桥梁模式


定      义:将抽象和实现解耦,使得两者可以独立的变化

优      点:

             1、抽象和实现分离,在该模式下,实现可以不受抽象的约束,不用再绑定在一个固定的抽象层次上

             2、优秀的扩充能力

             3、实现细节对客户透明

缺      点:

应用场景:

             1、不希望或不适用继承的场景,例如继承层次过渡,无法更细化设计粒度等场景,可以考虑用桥梁模式

             2、接口或抽象类不稳定的场景,明知道接口不稳定还想通过实现或者继承来实现业务续期,那是得不偿失

             3、重用性要求较高的场景

聚合与合成原则:尽量使用聚合或者组合,尽量不使用类继承

对象的继承关系是在编译时就定义好的,所以无法在运行时改变从父类继承的实现 。子类的实现与它的父类有着非常紧密的依赖关系,以至于父类实现中的任何变化必然会导致子类发生变化。当需要复用子类时,如果集成下来的实现不符合解决新的问题,则父类必然重写或被其他更合适的类替换。这种依赖关系限制了灵活性并最终限制了复用性。

应用案例:

             先来看看UML类图:

设计模式利剑23--桥梁模式_uml

                  Abstraction:业务抽象类,定义一个抽象接口,维护对Impementor的引用.

                 RefinedAbstraction:具体实现类,被提炼的抽象

                Implementor:定义一个抽象实现类,此抽象类与Abstraction类不一定完全相同。Implementor类提供了一些原始的操作,而Abstraction类是对这些原始操作一个更高层次的封装.

               ConcreteImplementorAConcreteImplementorA:具体实现

                举例,一个公司可以生产多种产品,并且公司随时可以转型生产其他产品,那么这样,公司于产品之间就是一个多变的情况,这个时候考虑用桥梁模式来解决比较恰当,看UML类图如下:

设计模式利剑23--桥梁模式_父类_02

当系统有多维角度分类时,而每一种分类又有可能变化,可以考虑使用桥接模式

举报

相关推荐

0 条评论