第一段代码基本上是抄书上的。人类下面是一个个具体的装扮动作，现在要加入“超人”的打扮
，就是在人类下再加入“红色披风”、“蓝色紧身衣”、“内裤外穿”。应该也不算太有问题。
即使人类的代码被锁死了，也可以继承一个新人类，加入以上几个装扮。如6-2.cs
但前面说的工厂模式，至少也要复习一下吧！6-3.cs代码写出来后，我不禁要问：这是工厂模式
吗？工厂模式的定义是什么？
再写策略模式，策略模式主要好处是客户端只要一个接口，我写出来，但各种穿法是一个个独立
的类，而这个类不是一直用的，而是用一次就扔掉，然后又用另一个类，因此这两种模式写出来
的代码都是感觉不好的。没那么顺。
理想情况下，要达到什么效果？第一服装的增加不会影响以前的客户端代码，第二服装的增加不
必开放以前服装的代码，第三人类与服装类应该是独立的两个类，人类穿什么，只能从现有的服
装类中挑选，并且允许多项挑选，如xc.Wear("TShirts", "BigTrouser", "Sneakers" ...);
装饰模式Decorator
模式用UML图体现，有用到两种类型：一是继承，空三角+实线，另一种是聚合，菱形+实线箭头。
其中提到了5个类，分别是：组成类，具体组成类，装饰类，具体装饰类A，具体装饰类B
它们关系是组成类衍生出具体组成类与装饰类，装饰类再衍生出各个具体装饰类，装饰类与组成
类有着聚合关系，装饰类指向组成类，即装饰类包含组成类（虽然大雁与雁群很好理解，但装饰
与组成就不好理解了）。
这样说来，人类与服饰类共用一个类，好象与常识不合吧！
共用的这个类，提供一个方法Show，人类继承下来，服饰类也继承下来。
即使把书中的例子完全输入进去，我也看不出什么名堂，好象是几个类，然后通过各种方法一级一级地串起来，由最后一级将几个类的操作全部体现出来。
装饰模式是利用SetComponent来对对象进行包装，这样每个装饰对象的实现就和如何使用这个对象分离开了，每个装饰对象只关心自己的功能，不需要关心如何被添加到对象链当中。
装饰模式是为已有功能动态地添加更多功能的一种方式。在起始的设计中，当系统需要新功能的时候，是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为，但这种做法的问题在于，它们在主类中加入了新的字段，新的方法和新的逻辑，从而增加了主类的复杂度，而这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要。而装饰模式却提供了一个非常好的解决方案，它把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地、按顺序地使用装饰功能包装对象了。
这里要问的是对象链是在什么情况下使用的？装饰类有必要与主类同源吗？
对于不想让主类负担过重，这一点是可以理解的，我可以想象即使是穿一个“破球鞋”，那也是有很多学问，主类如果去管，那太累了。甚至主类根本不必知道有其它装饰类的存在，因为装饰类可以多得像米一样，谁能知道那就是大百科全书了。
为了实现以上两点，非要装饰类同源吗？
我设想一种情况：有个明星，去参加一个演唱会，他要经过几个专业美容师打理一下，如发型设计师，面部美容师，服饰设计师，设计一个程序。设计好后，自己对这个没有用任何设计模式的程序反而感到满意。——无知者胆大