设计模式----装饰模式
先看定义：在不必改变原类文件和使用继承的情况下，动态的扩展一个对象的功能，通过创建一个包装对象，也就是装饰来包裹真实的对象。简单来看，可以想象一个人穿衣服，他的选择有衬衫、长裤、短裤等，你定义一个具体的人，一件一件的给他穿上衣服即装饰这个对象。
例子，定义一个类people：
.一个衣服的类，继承people:
T恤类：
短裤类：
长裤类：
衬衫类：
4个具体的衣服类都继承clothes类，都重写了showClothes方法。
测试类：
初始化People，通过setDecorator方法，给小明穿衣服，最后打印出来，就是一个穿上衣服的小明，装饰模式也是遵循设计模式开发-封闭原则，尽量不改变原有的类、方法，通过新加类来满足新的业务需求，以后新加鞋子，也是新创建个鞋类继承clothes，最后再通过声明鞋类，给小明穿上，就能满足。
以下情况使用Decorator模式
1. 需要扩展一个类的功能，或给一个类添加附加职责。
2. 需要动态的给一个对象添加功能，这些功能可以再动态的撤销。
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。
4. 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。
我写的例子是个简化版的，正常的装饰模式是包含4个角色：
（1）抽象构件（Component）角色：给出一个抽象接口，以规范准备接收附加责任的对象。
（2）具体构件（Concrete Component）角色：定义一个将要接收附加责任的类。
（3）装饰（Decorator）角色：持有一个构件（Component）对象的实例，并实现一个与抽象构件接口一致的接口。
（4）具体装饰（Concrete Decorator）角色：负责给构件对象添加上附加的责任。
我把抽象构件和具体构件合并了，因为我例子只有一个具体的人，以后需要多个对象，可以拆开，简化原则：（2）具体构件（Concrete Component）角色：定义一个将要接收附加责任的类。
（3）装饰（Decorator）角色：持有一个构件（Component）对象的实例，并实现一个与抽象构件接口一致的接口。
（4）具体装饰（Concrete Decorator）角色：负责给构件对象添加上附加的责任。
1. 如果只有一个Concrete Component类而没有抽象的Component接口时，可以让Decorator继承Concrete Component。
2. 如果只有一个Concrete Decorator类时，可以将Decorator和Concrete Decorator合并。
UML实例图：
例子很简单，简单写简单看，有什么问题，大家一起探讨。
参考书籍 《大话设计模式》