5装饰模式

装饰模式：Decorator1、基本原理在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？这就是本文要讲的Decorator模式。装饰模式（别名Wrapper）是在不必改变原类文件和使用继承的情况下，动态的扩展一个对象的功能。它通过创建一个包装对象，也就是装饰来包裹真实对象，提供了比继承更具弹性的代替方案。装饰模式一般涉及到的角色抽象构建角色(Component):给出一个抽象的接口，以规范准备接受附加责任的对象。具体的构建角色(ConcreteComponent)：定义一个将要接受附加责任的类。抽象的装饰角色(Decorator):持有一个抽象构建(Component)角色的引用，并定义一个与抽象构件一致的接口。具体的装饰角色(ConcreteDecorator):负责给构建对象“贴上”附加的责任。2、优缺点优点Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。把类中的装饰功能从类中搬移出去，这样可以简化原有的类。有效地把类的核心功能和装饰功能区分开了。通过使用不同的具体装饰类以及这些装饰类的排列组合，可创造出很多不同行为的组合。缺点这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性。装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。符合的设计原则：多用组合，少用继承。利用继承设计子类的行为是在编译时静态决定的，且所有的子类都会继承到相同的行为。如能够利用组合扩展对象的行为，就可在运行时动态进行扩展。类应设计的对扩展开放，对修改关闭。3、适用情况1.需要扩展一个类的功能，或给一个类添加附加职责。2.需要动态的给一个对象添加功能，这些功能可以再动态的撤销。3.需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。4.当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。4、应用举例1、送生日蛋糕：MM们要过生日了，怎么也得表示下吧。最起码先送个蛋糕。蛋糕多种多样了。巧克力，冰淇淋，奶油等等。这都是基本的了，再加点额外的装饰，如蛋糕里放点花、放贺卡、放点干果吃着更香等等。分析：方案1:如果采用继承会造成大量的蛋糕子类方案2、蛋糕作为主体，花，贺卡，果仁等是装饰者，需要时加到蛋糕上。要啥我就加啥。2、极品飞车喷涂鸦：“极品飞车”这款游戏中有对汽车进行喷涂鸦的功能，而且这个喷涂鸦是可以覆盖的，并且覆盖的顺序也影响到最后车身的显示效果，比如可以是红色火焰、紫色霞光等3、JavaI/OAPIjavaIO中需要完成对不同输入输出源的操作，如果单纯的使用继承这一方式，无疑需要很多的类。比如说，我们操作文件需要一个类，实现文件的字节读取需要一个类，实现文件的字符读取又需要一个类....一次类推每个特定的操作都需要一个特定的类。这无疑会导致大量的IO继承类的出现。显然对于编程是很不利的。而是用装饰模式则可以很好的解决这一问题，在装饰模式中：节点流（如FileInputStream）直接与输入源交互，之后通过过滤流（FilterInputStream）进行装饰，这样获得的io对象便具有某几个的功能，很好的拓展了IO的功能。5、其他5.1装饰模式和继承的比较装饰模式继承用来扩展特定对象的功能用来扩展一类对象的功能不需要子类需要子类动态地静态地运行时分配职责编译时分派职责防止由于子类而导致的复杂和混乱导致很多子类产生，在一些场合，报漏类的层次更多的灵活性缺乏灵活性对于一个给定的对象，同时可能有不同的装饰对象，客户端可以通过它的需要选择合适的装饰对象发送消息对于所有可能的联合，客户期望很容易增加任何的扩展困难扩展5.2、模式的简化：1.如果只有一个ConcreteDecorator类时，可以将Decorator和ConcreteDecorator合并。2、如果只有一个ConcreteComponent类而没有抽象的Component接口时，可以让Decorator继承ConcreteComponent。总结Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。