装饰模式Decorator

装饰模式，是对客户端透明的方式扩展的功能，是用于替代继承关系的一个替代方案。

类图：

装饰模式里面包含了抽象构件对象角色：该角色是规范准备接收附加责任信息。

具体构件角色：定义要被装饰的类。

装饰角色：拥有一个构件实例，该实例用于接收存放要被装饰的类。

具体装饰类：负责给具体构件对象增加附加的责任。

这是我对装饰模式的简单理解，如有偏差请各位大牛指出。

如果要实现一个类ConcerteCommentA，而该类是对现有类ConcerteComment的扩展。最简单的方法就是使用继承关系了，这样可以方便的实现对类的扩展。父类和子类之间的这种继承关系，其实耦合性很大，而我们目前的开发思想是要尽量降低耦合性，提高可扩展性。在对类的设计中如果使用多重继承或使用太多的继承会导致类出现不可控制的庞然大物。所以设计中有关业务的方法类尽量不要使用继承。GOF给我们提出了一个很好的解决的方法，使用装饰模式。

装饰角色类Decorator中有一个Comment的对象，可用于存放要被装饰的对象。

具体装饰类ConcerteCommentA和ConcerteCommentB中可以对ConcerteComment进行增加新的责任。

如何实践装饰模式呢？

以我自己对装饰模式的理解我提出了一下几点实践意义，请大侠指点

首先分析要被装饰的类，提炼出抽象构件角色中的附加责任信息，这样就可以对后面的装饰类加以规范。我认为这是最重要的，也是核心所在。

第二步：创建装饰类Decorator，继承Comment类，包含了Comment的一个实例。然而继承需要实现Comment的Operation方法，这里的实现方法使用的是Comment的实例调用自身的Operation。

第三步：具体装饰类都继承了装饰类，这里就可以对需要装饰的类进行相应的增加功能和重写方法。