最新消息:

java设计模式之装饰者模式

JAVA 大步 815浏览 0评论
GoF 定义:动态的往一个对象添加其他职责。装饰者为子类提供了一个灵活的选择去扩展共更能。
• 装饰模式又名包装(Wrapper)模式
• 装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案
• 装饰模式以对客户透明的方式动态的给一个对象附加上更多的责任。换言之,客户端并不会觉得对象在装饰前和装饰后有什么不同。
• 装饰模式可以在不创造更多子类的情况下,将对象的功能加以扩展。
• 装饰模式把客户端的调用委派到被装饰类。装饰模式的关键在于这种扩展完全是透明的。
• 装饰模式是在不必改变原类文件和使用继承的情况下,动态的扩展一个对象的功能。它是通过创建一个包装对象,也就是装饰来包裹真实的对象。
 
 
• 装饰模式的角色:

– 抽象构件角色(Component):给出一个抽象接口,以规范准备接收附加责任的对象。
– 具体构件角色(Concrete Component):定义一个将要接收附加责任的类。
– 装饰角色(Decorator):持有一个构件(Component)对象的引用,并定义一个与抽象构件接口一致的接口
– 具体装饰角色(Concrete Decorator):负责给构件对象“贴上”附加的责任。

 
 
• 装饰模式的特点:
– 装饰对象和真实对象有相同的接口。这样客户端对象就可以以和真实对象相同的方式和装饰对象交互。
– 装饰对象包含一个真实对象的引用(reference)
– 装饰对象接收所有来自客户端的请求。它把这些请求转发给真实的对象
– 装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运行时,不用修改给定对象的结构就可以在外部增加附加的功能。在面向对象的设计中,通常是通过继承来实现对给定类的功能扩展。
 
 
 
• 装饰模式
– 用来扩展特定对象的功能
– 不需要子类
动态
运行时分配职责(更多的是体现在不同功能的动态组合组装上)
– 防止由于子类而导致的复杂和混乱
– 更多的灵活性
– 对于一个给定的对象,同时可能有不同的装饰
对象,客户端可以通过它的需要选择合适的装
饰对象发送消息。
 
 继承
– 用来扩展一类对象的功能
– 需要子类
 静态
编译时分派职责
– 导致很多子类产生
– 缺乏灵活性

 

概念
这个模式的主要原则就是说,我们不能修改已经的功能,但是我们可以扩展它们的功能。换句话说,这个模式
是对扩展保持开放,但是对修改保持关闭。这个核心概念的应用场景:当我们想对某些特殊对象添加一些特殊的功能,而不是整个类的时候。
java中的IO api就是属于装饰者模式。例如,使用FileInputStream来读取文件,然后在传递给DataInputStream来增加readInt、readDouble等功能。

 

现实生活中的例子
假设你已经有了一个房子。险隘你决定去添加另外一层,显然地,你不想改变已有的楼层。你可能像去改变新的楼层的设计以确保不会影响已有的楼层架构。

 

计算机世界的例子
假设在一个基于GUI的工具包中,我们想添加一些边框属性。我们可以通过继承实现。但是这不能视为最好的解决方案,因为我们的用户或客户对创建不能有完全的控制权。关键在于这种方式是静态的 (意思是说,使用继承的方式,类的职责在编译时就固定下来了)
装饰者模式可以给我们提供一个更灵活的实现:我们将这个组件封装到另外一个对象中。这个封装的对象叫做“装饰者(decorator)”。它符合它所封装的对象的接口。它将请求转发到这个组件。它可以在转发之前或之后执行其他操作。通过这种概念,我们可以添加无数个职责。
 

描述

我们不尝试改变原有的doJob()方法的功能。添加 两个装饰者, ConcreteDecoratorEx_1和ConcreteDecoratorEx_2 来加强功能,但是原有的doJob()方法不影响这个新增的功能。
 
 
UML

 原有的抽象类:
具体实现类:
装饰者的抽象类,继承自Component:
装饰者1:
装饰者2:
客户端:
原来的对象(ConcreteComponent )先经过装饰者1(ConcreteDecoratorEx_1) 来添加一个功能,然后再把装饰者1作为装饰者2(ConcreteDecoratorEx_2)的参数,其实就是继续对ConcreteComponent 进行装饰
输出:
Note
装饰者模式的主要优点是什么?

1. 在不会影响系统中已有的对象的情况下,我们能添加新的功能到某个特定的对象上。
2. 我们可以增量编码。例如,我们可以先实现一个简单的类,然后根据需要,一步一步的添加装饰者对象到其中。这样,我们就无需在一开始就考虑每个可能的使用场景。另一方面,我们必须承认,一开始就显示一个复杂的类,接着扩展它的功能,这是一个更复杂的过程。

 

 

 
 
这个模式与继承有什么区别?
 

我们能够通过简单的附加或分离 装饰者来添加或移除职责。但是如果是简单的继承技术,我们需要去为新的职责创建一个新的类。所以,这样会导致系统中有太多的类,这可能使得系统变得复杂。

这个模式的主要缺点?

首先,如果我们足够小心,那么就没有明显的缺点。但是,如果我们在系统中创建太多的装饰者,那么可能会导致系统难以维护和调试。同时,这些装饰者会创建不必要的困惑,导致代码阅读性会有所下降。

 

个人感觉装饰者模式和代理模式有点类似,都是让原来的类去执行实际任务,而装饰者或者代理者只是在前或后增加一些功能(控制)而已。

翻译自:java design Patterns ,外加自己的感悟

 

转载请注明:大步's Blog » java设计模式之装饰者模式

SiteMap