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

 

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

优      点：

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

             2、优秀的扩充能力

             3、实现细节对客户透明

缺      点：

应用场景：

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

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

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

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

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

应用案例：

             先来看看UML类图：

         

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

                 RefinedAbstraction类：具体实现类，被提炼的抽象

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

               ConcreteImplementorA，ConcreteImplementorA类：具体实现

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

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