设计模式----装饰模式

                    设计模式----装饰模式

        装饰模式，就是将传统繁琐的设计模式简单化，不需要许多的子类，也能实现同样的功能的一种设计模式。

        例子如下：

     --------------------------

普通继承模式实现

A 发镖

B 变身

C 无敌

M1: A

M2: B

M3: C

M4:A B      

M5:A C

M6:B C

M7:A B C

---------------------------

装饰模式

M

 |--M1

 |--M2

 |--M3

A B      : new M2(M1)

A C      : new M3(M1)

B C      : new M3(M2)

A B C    : new M3(M2(M1))

由上例可看出，原本的8个子类缩短了一半。

在这样简单的例子中，就可以清晰的感受到装饰模式的效果，想像一下在做某些繁琐的游戏时，这种效果会被继续扩大化。

还发现了两种关系  is----a    与   has-----a ，如

 

下例：

这里装饰者Decorator与IUSB之间的关系满足is – a关系，即Decorator is-a IUSB,即子类一定是父类，而父类不一定是子类。这里虽然是接口，但在这儿一样适用，话句话说，人一定是动物，而是动物就不一定是人了。

 

装饰者Decorator同时还与IUSB直接满足has – a的关系。两个类之间要进行通信，常在一个类中引用另一个类，这个在WinForm种的窗体之间通信用的多，一个窗体如果要访问另外一个窗体的public属性的属性或方法，常引用要访问的窗体作为私有成员变量。这是UML种的关联关系。

 

Is---a关系

 

也就是说IUSB包含了Decorator ,换句话说Decorator是IUSB的一部分，所以IUSB可是是完整的Decorator，但Decorator不能代表IUSB。

 

至于has---a关系

 

我认为说的是两者信息间的传递阶级，谁大谁小。

继续往下走，了解了装饰模式是为已有功能动态地添加更多功能的一种方式。

那什么叫做为已有功能动态地添加更多功能的一种方式呢？ 我认为简单的说，就是将一个诺基亚1110变成Iphone4，也就是说使其增加了许多自身不具备的功能。

那装饰模式应该怎么写呢？我感觉应该先把公共类写出来，也就是最基本的效果写出来，

然后用这些最基本的效果按照自己想要的方向组合，具体的代码我还不是很熟悉，所以现在对于装饰模式其实还是出狱一知半解的阶段，半解不到。

作者最后的总结很好

装饰模式总结

装饰模式是为已有的功能动态地添加更多功能的一种方式。

当系统需要新功能的时候，若向旧的类中添加新的代码，这些新加的代码通常装饰了原有类的核心职责或主要行为，但这种做法的问题在于，它们在主类中加入了新的字段，新的方法和新的逻辑，从而增加了主类的复杂度，而这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要。而装饰模式切提供了一个非常好的解决方案，他把每个要装饰的功能都放在单独的类中，并让这个类包装他所要装饰的对象，因此，当需要执行特殊行为时，客户端代码就可以在运行时更具需要有选择地、顺序地使用装饰功能包装对象了。

适用性 

　　在以下情况下应当使用装饰模式：

　　1.需要扩展一个类的功能，或给一个类增加附加责任。 

　　2.需要动态地给一个对象增加功能，这些功能能再动态地撤销。 

　　3.需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。