装饰者模式：动态地给一个对象添加一些额外的职责，就增加功能来说，Decorator模式比生成子类更为灵活。
Decorator模式的工作原理是：可以创建始于Decorator对象（负责新的功能的对象）终于原对象的一个对象“链”。
图1装饰者链
装饰者模式隐含的是通过一条条装饰链去实现具体对象，每一条装饰链都始于一个Componet对象，每个装饰者对象后面紧跟着另一个装饰者对象，而对象链终于ConcreteComponet对象。
装饰者模式 ：动态地将责任附加到对象上.若要扩展功能,装饰者提供了比继承更有弹性的替代方案。
装饰者模式类图:
问题: 说装饰者模式比用继承会更富有弹性,在类图中不是一样用到了继承了吗?
说明:装饰者和被装饰者之间必须是一样的类型,也就是要有共同的超类。在这里应用继承并不是实现方法的复制,而是实现类型的匹配。因为装饰者和被装饰者是同一个类型,因此装饰者可以取代被装饰者,这样就使被装饰者拥有了装饰者独有的行为。根据装饰者模式的理念,我们可以在任何时候,实现新的装饰者增加新的行为。如果是用继承,每当需要增加新的行为时,就要修改原程序了。
具体案例:有存储在数据库中的新闻,有存储在XML文件中的新闻(一般都是推荐新闻,内容比较少)。
在没有接触设计模式时,都是针对具体实现编程,读取数据库新闻时直接写一个基于数据库的方法,读取推荐新闻时再写一个基于XML的方法,两种方法之间没有任何的关系.当时觉的这样实现也没什么不好。可是你总会发现这两种方法在实现上有很多相同的地方,都是读取出一个新闻标题集合来绑定数据源,只是取数据源的方法不同而已。为了方便管理,我们可以定义一个统一的接口来约束这两种方法。这种做法也足够满足读取不同载体的新闻要求。可是如果在读取新闻时要做其它的操作呢?例如:给读取出来的新闻的人气加一。这个时候我们就要修改原程序,这样有背于"对扩展开放,对修改关闭"的编程原则。如何解决呢?这就是装饰者模式出场的时候了。
为了说明一些装饰者模式的类图和概念,下面就要讲新闻模块和装饰者模式的关联了。
例如:在展示新闻的同时给读取出来的新闻的人气加一,同时把新闻标题加入到RSS中,如果是用继承,就要往超类中增加相应的方法,如果是一个新增行为还是可以忍受的,如果此模块有不断增加业务的可能,那是不是要每次都要修改原程序呢?我想所有的朋友都不希望这样做。我们希望当有新的行为时才往旧对象上加,是在运行时加,并不是一开始就加。
解决方案：这里我应用装饰者模式设计来满足这种不断新增业务的需求:
1：定义根据不同载体读取新闻方法的抽象类:
public abstract class Component_News { /// <summary> /// 取新闻 /// </summary> /// <returns></returns> public abstract List<News> getListOfNews(); }