设计模式总结－decorator模式.doc

设计模式总结-Decorator模式设计模式总结,Decorator模式一、Decorator模式的定义:“Decorator”一词在英文中的意思是“装饰工”的意思,在设计模式中“Decorato模式”的作用也是“动态地给对象增加一些职责”。请注意:这句话中有2个重点的地方:?动态:也就是说无法预先在编译阶段就知道职责的具体内容和添加时机,什么时候添加什么功能完全由客户在运行时刻规定。?增加:“Decorator模式”往往用于在现有功能的基础上针对不同的对象,添加一些不同的功能,实际上我们还可以改变行为的流程。二、Decorator模式的好处:我们知道,有时候在同一个运行环境下,由于不同对象具有不同的特性导致了它们在执行同一种类型操作时,可能存在一些细小的差别,这些差别可能体现在:第一参数不同第二过程不同第三方式不同那么针对这三种情况我们可以采取的解决方法有两种:第一采用继承的方式。定义一个父类的抽象方法,由不同的子类各自实现不同的操作,但一旦子类一多势必带来类的数量膨胀的问题,难以管理;其次如果只是一些局部的细微差别而导致了必须重写整个过程或方法,那么必将导致出现大量的重复代码(即功能相同部分的代码)。我曾经看过一些项目,里面存在了大量的重复代码,到处都是“Copy-Paste”.只是修改了某处的关键参数而已。而“Duplicatecode”正是《重构-改善既有代码的设计》一书中提到的首要“异味”,这意味着一旦公共部分的功能改变了,那么你有可能需要重新编译几个甚至十几个子类。第二采用“Decorator模式”。首先将功能分解,分成若干个小块,这是为了后面我们可以动态地重组。其次将功能部分抽取出来成为一个接口,通过一个实现了接口的基类完成基本的共有功能。一旦我们需要在基类的功能基础上添加或改变流程,我们就可以通过“Decorator类”实现接口,在接口的实现方法中增加、改变方法的功能或流程。比较上面这两种做法,我们可以看到使用了“Decorator模式”后,代码更加简洁了,可重用性和可扩展性更高了。其次由于可以在构造“Decorator类”的过程中传递参数,我们可以动态的增加、改变原有的功能、流程,而相同部分的功能则委托给基类去完成。最后由于“油漆工”在“被油漆物”外面刷了一层油漆,里面怎么改变对外界来说是透明的。三、Decorator模式的适应场合:Decrator模式的适用场合:1).在运行时刻由用户动态决定加入的方式和时机,无法在编译期间决定2).需要改变的行为太多,用继承会导致复杂性的增加四、Decorator模式与Adapater、Builder模式的区别:Adapter和Decorator模式的区别:1).前者关注的是如何将两个本来互不相关的类糅合到一起,后者关注的是如何在原来功能的基础上做一些小的调整Builder和Decorator模式的区别:1).前者关注的是对象的构建,后者关注的是对象功能的添加、个性化2).前者主要用于GUI界面构建对象的场合、后者主要用于动态添加功能、改变流程的场合设计模式总结,Decorator模式(二)前面我们看了Decorator模式的一下理论基础,知道了Decorator模式的适应场合是:在运行时刻由用户动态决定加入的方式和时机,无法在编译期间决定。下面我们就以一个实际的例子来了解一下Decorator模式的实际应用。一、应用场景:假设我们已经存在这样的一个程序:1).该程序从一个列表中拿出所有的用户名单,然后逐个向用户发送一句信息。2).现在我们又增加了一个新的需求:在发送之前检查一下该用户是否存在于黑名单中,如果是的话则不发送给该用户。3).是否进行检查则动态根据用户的当时需要来决定。二、需求分析:从上面的情况分析,如果我们采用继承的方式,重新编写一个带有过滤功能的发送程序,则必须完全改写原有的发送方法,插入过滤的过程。如果我们采用Decorator模式的话,可以怎么做呢,首先分析一下需求的公共部分,相同的部分都是发送信息,不管是否需要进行过滤。也就是说只有发送的方法拿到数据,它就不管三七二十一发出去了,所以这个功能应该可以被抽象成一个接口。接下来我们来看一下,既然新的功能只是在旧的功能之前插入了“过滤”这一简单的过程,原有的功能保持不变,所以我们完全可以把旧的功能委托给老的程序来进行。既然是委托了那么必然在新的类里面要含有一个旧的对象的引用。最后如何实现“动态插入过滤功能”呢,我们看一下前面的接口,如果我们实现了接口,那么在其实现方法中就可以重写原来的方法,增加过滤功能了。三、系统设计:我们来看一下下面这张图,明确一下各个对象之间的联系在这张图中我们看到:我们抽象出了一个接口:ISendMessage接口,原有的SendMessageImpl类和新增的SendMessage