设计模式笔记心得(2)--Bridge模式,Decorator模式

Bridge模式
Bridge的核心就是将抽象和实现分离, 让二者独立变化
当需要将类的行为和属性分离的时候,可以采用Bridge模式, 在抽象体实现属性, 在实现体实现行为, 从而达到属性和行为能独立变化, 他们之间通过桥接(也就是将二者绑定, 在抽象类中隐藏)的方式来进行关联, 而且这种桥接绑定的关系是可动态改变的, 这也是与继承相比最大的优点, 有时候我们也可以将其理解为代理模式的一种演化, 将行为代理给各个不同的行为实现类来处理.
该模式在行为和属性存在交叉重合的场景下非常有用, 比如网上那个coffee的例子可谓bridge模式的经典例子, coffee有两种属性:大杯和中杯, 同时有两种行为:加奶和不加奶, 这样属性和行为可以交叉组合而得到不同的coffee.

Bridge模式是使用组合而非继承的典型模式

Decorator模式
装饰器模式的两个要点:
1.装饰器类必须继承被装饰类;
2.装饰器类必须持有被装饰类实例;
采用Wrapper模式的说法可能更形象一些, 实际上就是在具体类的基础上一层层添加所需要的功能, 将被装饰的对象采用不同的装饰类层层包裹起来, 同Bridge模式一样, 他也采用组合的方式来将某个功能添加到抽象类之上, 当需要将各种装饰效果进行组合的时候可以避免生成多个抽象类的子类.

为何采用Decorator而不是普通的继承?
一般通过继承来扩展一个功能, 最简单的就是对要扩展的方法进行复写, 另一个就是添加抽象方法交给子类自己去实现, 功能越多,添加的抽象方法就越多, 而这些方法都是静态的, 一旦要派生具体子类就必须实现(或者空实现) , 而这些抽象方法的调用方式也是固定的(除非复写再改写), 这样显然是不够灵活的做法, 而且如果存在多种功能的组合会导致派生的子类成几何数增长, 当出现这种情况时我们就不应该使用简单的继承,而应该进行重构使用其他的设计模式来更好的满足我们的需求.

Decorator和Bridge的区别
Decorator是对已有功能的增强, 装饰类都是围绕被装饰类已有的功能而展开的, 无论装饰类怎么变, 它都必须围绕被装饰类来变化(或者是围绕二者公共的接口来变化), 因为对于客户程序来说, 调用装饰前后的对象应该是一致的. 而Bridge模式是将行为从被桥接对象(抽象类)中分离出去, 完全放到实现类中去实现, 行为实现将更少的受到被桥接对象的限制. 所以如果这种约束是必要的,就可以采用Decorator模式, 反之则可以采用Bridge模式

注意事项
Decorator, Bridge采用的是组合模式, 不可避免的需要创建一些类实例, 相对于继承来说内存消耗要相对大一些, 比如使用Decorator除了需要new装饰器类实例还需要new被装饰类, 因此出于效率的考虑new出来的对象应该尽可能的小, 也就是要做到new的对象类必须职责单一, 按需来new对象, 对于Decorator来说, 抽象对象的实现应该尽可能的简单, 将复杂的东东放到装饰类中实现, 而Bridge则要将不同的职责封装到行为实现中