评设计模式3

9.Decorator 模式（装饰模式）

   此模式的核心是在RunTime，通过把对象嵌入同一基类的另一对象的方式组合使用对象，从而为实例动态添加功能。

   此模式的作用和Bridge模式是一样的，都是达到组合使用对象的功能，区别是：

   1) Bridge模式是在DesignTime就设计好对象组合的方式，而Decorator模式是在RunTime进行对象组合。

      也就是说Bridge模式是使用线性包装的，在DesignTime，所有组合次数（调用路径）都可推测出来。

      而Decorator模式则是使用递归式包装，组合次数（调用路径）是无法在DesignTime推测出来，因为它是在RunTime以层层包裹的方式进行组合的，就像包粽子一样，你包几层粽页，谁能想出来？！再打个不好听的比喻，它可以像屎克郞滚的牛屎一样，越滚越大，呵呵。     

   2) Bridge模式所组合的对象可以不是同一基类的对象，而Decorator模式所组合的对象都是
      同一基类的对象。

  

   此模式涉及到三种类

   1）基类A

   2）子类B

   3）装饰基类(Decorator/ Wrapper)C及装饰子类D

       此系列类是此模式的实现要点。关键有两处：

       a) 装饰基类C和子类B一样，也继承自同一基类A

       b）装饰基类C使用Bridge模式引用A或B的实例。

           一般来说，在C或D的构造函数中就把A或B的实例传入

 

    而在客户端好的调用方式，才会体现此模式的优点，就是：

    类A1使用装饰器B1进行包装,然后使用另一装饰器B2对B1进行包装，再然后用另一装饰器B3对B2进行包装…，如此类推

  

   一般此模式用于类的一部分功能比较稳定，而另一部分功能则不稳定，有时需要，有时不需要。这时就把不稳定的功能外包给装饰器类实现，从而实现的功能的动态装卸。

     这个模式很像搭积木。也很像高级数码相机和其非标配的扩展设备(如各种镜头、三脚架、打印机、包等）间的关系，完成不同的功能可通过加装设备的方式完成（主镜头不变）。而Bridge模式就像数码相机和其标准镜头的关系一样，相机必须有一个镜头，但镜头可换成其它镜头，完成不同的功能需要更换镜头。

10.Composite Pattern 模式（组合模式）

    此模式的核心要以树形结构的方式来管理多个同宗实例间的引用关系，从而方便达到一定目地。

    详细来说，基类(接口)和子类要进行恰当的设计，从而达到以下效果：创建一组子类实例（不一定是同一子类的实例），然后实例间进行单向引用（可以一个实例引用多个其它实例，也可以不引用），从而建立一个子类实例的树形引用链，从而使客户端可以以树形递归的方式访问各个实例，或便于把此组实例所表述的信息以树形的方式在视图层进行展示。

    从效果来看，不管子类实例有没有能力引用其它实例，客户端都将按统一的接口处理实例。

   

   此模式中，基类或基接口通常称为 Component；可以引用其它同宗子类的实例的子类，通常称为 Composite；反之，不能引用其它同宗子类的实例的子类通常称为 Leaf。

  

   要实现上述效果，有两种设计方式：   

    1）方式一（有人称之为透明式）

        所谓透明式，指的是大伙都一样

        a) Component 至少包含或规定一个用于添加其自身或子类的实例的方法，通常叫Add()或Insert().

            如果想完善的话，还可以添加一些移除、查找其自身或子类的实例的方法，比如Remove()、FindBy()等      

        b）子类或实现接口的类上，

           Composite 要重写或具体实现第一点提到的Add()等方法。

           Leaf 则可以不管这些方法，或者实现个空方法，或者抛出异常进行警告。

    2）方式二（有人称之为安全式，指的是调用安全）

        a) Component 不需做任何特殊处理     

        b）只在Composite 上添加Add()等方法。

11.Facade 模式（门面模式）

    看到这个模式及例子，觉得，噢，天那，这也叫一种模式。

    简单点说，老土点儿说，不就是写公共函数吗？

    这不就是很多Util、Helper类的实现方法和目地吗？只不过它是强调对子系统的调用的封装罢了。  

    太普通了。不过，的确是一种封装方法。   

 

    那它为什么会位列仙班？我想它是想强调两点：

    1）你愿意直接跟沷妇（子系统）打交道吗？不愿意？那就请个职业律师来对付她吧。

        强调要对子系统的调用进行封装。

    2）此点最关键，强调此模式在架构开发中作用。也就是说要从架构的角度来看此模式存在必要性

        在架构中使用此模式来简化或隐藏对底层模块或其它系统的调用。

        在N层开发架构中，使用Facade类来实现信息、请求在层间的分发，也就是把信息、请求传到合适的层中

 

    很多时候，不恰当的例子不但没有说明模式的精妙之处，反倒是帮了倒忙，让人觉得不过尔尔，让人觉得没有使用模式的必要性。一个是很多此模式的例子，一个是很多工厂模式的例子。

12.Flyweight Pattern 模式（享元模式）

    此模式的核心就是构建一个对象池，作为一个缓存。

    缓存有啥好处，此模式就有啥好处。

    对象池怎么创建随你，能结合别的模式当然更好。

    .net中的例子，最典型的就是ADO.NET的数据库连接池。