《装饰模式》-课件设计.pptVIP

本章目标 理解装饰模式 学会运用装饰模式 从“小猪快跑”说起 “小猪逃命”游戏：一只小猪和一只灰狼，小猪最多5条命，灰狼每咬到小猪 一次，小猪就要少一条命，小猪的任务是要逃过灰狼的追咬到猪栏。 游戏分析 如果用继承实现这么多种效果的小猪：需要为小猪派生3*2*1=6个子类（有保护罩的小猪，奔跑速度加快的小猪，会趟水的小猪，既有保护罩又会趟水的小猪，奔跑速度快且会趟水的小猪，有保护罩且奔跑速度快的小猪，有保护罩、奔跑速度快且会趟水的小猪） 如果有四种苹果的话那你要为小猪派生4*3*2*1=24个子类； 如果有五种苹果...... 分析后果 继承带来的后果是：1. 子类无限膨胀；2. 维护性差，每增加一个效果，都要为之增加Cnn-C(n-1)(n-1)个子类 装饰模式 Decorator模式（别名Wrapper）：动态将职责附加到对象上。 装饰模式可以动态的给一个对象附加一些功能，对于扩展功能来说，装饰模式（合成）比生成子类的方式（继承）更加灵活。 装饰模式类图 模式代码 抽象构件：定义了具体构件和抽象装饰要实现的方法 具体构件：可以给这个对象添加一些职责 模式代码 抽象装饰者：抽象装饰者也实现了抽象构件的接口 模式代码 具体装饰者：继承自抽象装饰，负责具体的装饰 调用代码 调用思路：先把各自的对象造出来，然后依次进行渲染 运行结果 深入分析 Decorator与Component之间既是Is a...的继承关系，又是Has a...的组合关系。使用具体装饰类(ConcreteDecorator)来装饰具体构件对象(ConcreteComponent)，装饰完的对象依旧是个Component类型。 Decorator模式解决的是类的功能的多向扩展，而不是单纯的类的继承。 Decorator模式提供了比继承更灵活的功能扩展，通过使用不同具体装饰对构件对象的排列组合地包装，能够不同功能的组合。 分析“小猪快跑”游戏代码 装饰模式深入分析 装饰模式以一种对客服端透明的方式动态的对对象增加功能，是继承的一种很好的替代方案。 继承是一种面向对象语言特有的而且也是一种非常容易被滥用的复用和扩展的手段。继承关系必须首先符合分类学意义上的基类和子类的感谢，其次继承的子类必须针对基类进行属性或者行为的扩展。继承使得修改或者扩展基类比较容易；但是继承也有很多不足，首先继承破坏了封装，因为继承讲基类的实现细节暴露给了子类，其次，如果基类的实现发生了变化，那么子类也就会跟着，这时候我们就不得不改变子类的行为，来适应基类的改变。最后从基类继承而来的实现都是静态的，不可能在运行期（runtime）发生改变，这就使得相应的系统缺乏足够的灵活性。 由于以上诸多的原因，一般尽量是不使用继承来给对象增加功能，此时，装饰模式就是一种更好的选择了，这是因为：首先，装饰模式对客户端而言是透明，客户端根本感觉不到是原始对象还是被装饰过的对象，也就是说装饰模式对客户端而言是透明的；其次装饰者和被装饰对象拥有共同一致的接口，而且装饰者采用对被装饰类的引用的方式使用被装饰对象，这就使得装饰对象可以无限制的动态的装饰被装饰对象；最后装饰对象并不知道被装饰对象是否被装饰过，这就使得面对任何被装饰的对象，装饰者都可以采用一致的方式去处理。 本课程版权归北风网所有 欢迎访问我们的官方网站 * 北风网项目培训 讲师：石曼迪 设计模式——装饰模式 三种苹果 红苹果 保护罩 绿苹果 加速跑 黄苹果 会游泳 *苹果 其他效果 如何实现才能避免这些问题？ 1. 多用组合，少用继承。 利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展对象的行为，就可以在运行时动态地进行扩展。 2. 类应设计的对扩展开放，对修改关闭。 抽象构件：给出一个抽象接口，以规范准备接收附加责任的对象和抽象装饰器 具体构件：定义一个将要接收附加责任的类 抽象装饰：持有一个构件（Component）对象的实例，以用来对它进行装饰，并定义一个与抽象构件接口一致的接口。 具体装饰：负责给构件对象加上附加的功能 interface Component { void Operation(); } class ConcreteComponent : Component { public void Operation() { Console.WriteLine(ConcreteComponent Operation); } } abstract class Decorator :