- 浏览: 34781 次
- 性别:
- 来自: 上海
最新评论
动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。
适用性
1.在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责。
2.处理那些可以撤消的职责。
3.当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支 持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类
定义被隐藏,或类定义不能用于生成子类。
来分析下 JUnit 的使用是属于哪种情况。首先实现了比静态继承更加灵活的方式,动态
的增加功能。试想为Test 的所有实现类通过继承来增加一个功能,意味着要添加不少的功
能类似的子类,这明显是不太合适的。
而且,这就避免了高层的类具有太多的特征,比如上面提到的带有警报的抽象门类。
透明和半透明
对于面向接口编程,应该尽量使客户程序不知道具体的类型,而应该对一个接口操作。
这样就要求装饰角色和具体装饰角色要满足Liskov 替换原则。像下面这样:
Component c = new ConcreteComponent();
Component c1 = new ConcreteDecorator(c);
JUnit 中就属于这种应用,这种方式被称为透明式。而在实际应用中,比如java.io 中往
往因为要对原有接口做太多的扩展而需要公开新的方法(这也是为了重用)。所以往往不能
对客户程序隐瞒具体的类型。这种方式称为“半透明式”。
在 java.io 中,并不是纯装饰模式的范例,它是装饰模式、适配器模式的混合使用。
其它
采用 Decorator 模式进行系统设计往往会产生许多看上去类似的小对象,这些对象仅仅
在他们相互连接的方式上有所不同,而不是它们的类或是它们的属性值有所不同。尽管对于
那些了解这些系统的人来说,很容易对它们进行定制,但是很难学习这些系统,排错也很困
难。这是GOF 提到的装饰模式的缺点,你能体会吗?他们所说的小对象我认为是指的具体
装饰角色。这是为一个对象动态添加功能所带来的副作用
参与者
1.Component
定义一个对象接口,可以给这些对象动态地添加职责。
2.ConcreteComponent
定义一个对象,可以给这个对象添加一些职责。
3.Decorator
维持一个指向Component对象的指针,并定义一个与Component接口一致的接口。
4.ConcreteDecorator
向组件添加职责。
类图
例子
Component定义一个对象接口,可以给这些对象动态地添加职责。
public interface Person {
void eat();
}
ConcreteComponent 定义一个对象,可以给这个对象添加一些职责。
public class Man implements Person {
public void eat() {
System.out.println("男人在吃");
}
}
Decorator 维持一个执行Component对象的指针,并定义一个与Componect 接口一致的接口。
public abstract class Decorator implements Person {
protected Person person;
public void setPerson(Person person) {
this.person = person;
}
public void eat() {
person.eat();
}
}
ConcreteDectrator 想组建添加职责
public class ManDecoratorA extends Decorator {
public void eat() {
super.eat();
reEat();
System.out.println("ManDecoratorA类");
}
public void reEat() {
System.out.println("再吃一顿饭");
}
}
public class ManDecoratorB extends Decorator {
public void eat() {
super.eat();
System.out.println("===============");
System.out.println("ManDecoratorB类");
}
}
Test
public class Test {
public static void main(String[] args) {
Man man = new Man();
ManDecoratorA md1 = new ManDecoratorA();
ManDecoratorB md2 = new ManDecoratorB();
md1.setPerson(man);
md2.setPerson(md1);
md2.eat();
}
}
result
男人在吃
再吃一顿饭
ManDecoratorA类
===============
ManDecoratorB类
适用性
1.在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责。
2.处理那些可以撤消的职责。
3.当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支 持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类
定义被隐藏,或类定义不能用于生成子类。
来分析下 JUnit 的使用是属于哪种情况。首先实现了比静态继承更加灵活的方式,动态
的增加功能。试想为Test 的所有实现类通过继承来增加一个功能,意味着要添加不少的功
能类似的子类,这明显是不太合适的。
而且,这就避免了高层的类具有太多的特征,比如上面提到的带有警报的抽象门类。
透明和半透明
对于面向接口编程,应该尽量使客户程序不知道具体的类型,而应该对一个接口操作。
这样就要求装饰角色和具体装饰角色要满足Liskov 替换原则。像下面这样:
Component c = new ConcreteComponent();
Component c1 = new ConcreteDecorator(c);
JUnit 中就属于这种应用,这种方式被称为透明式。而在实际应用中,比如java.io 中往
往因为要对原有接口做太多的扩展而需要公开新的方法(这也是为了重用)。所以往往不能
对客户程序隐瞒具体的类型。这种方式称为“半透明式”。
在 java.io 中,并不是纯装饰模式的范例,它是装饰模式、适配器模式的混合使用。
其它
采用 Decorator 模式进行系统设计往往会产生许多看上去类似的小对象,这些对象仅仅
在他们相互连接的方式上有所不同,而不是它们的类或是它们的属性值有所不同。尽管对于
那些了解这些系统的人来说,很容易对它们进行定制,但是很难学习这些系统,排错也很困
难。这是GOF 提到的装饰模式的缺点,你能体会吗?他们所说的小对象我认为是指的具体
装饰角色。这是为一个对象动态添加功能所带来的副作用
参与者
1.Component
定义一个对象接口,可以给这些对象动态地添加职责。
2.ConcreteComponent
定义一个对象,可以给这个对象添加一些职责。
3.Decorator
维持一个指向Component对象的指针,并定义一个与Component接口一致的接口。
4.ConcreteDecorator
向组件添加职责。
类图
例子
Component定义一个对象接口,可以给这些对象动态地添加职责。
public interface Person {
void eat();
}
ConcreteComponent 定义一个对象,可以给这个对象添加一些职责。
public class Man implements Person {
public void eat() {
System.out.println("男人在吃");
}
}
Decorator 维持一个执行Component对象的指针,并定义一个与Componect 接口一致的接口。
public abstract class Decorator implements Person {
protected Person person;
public void setPerson(Person person) {
this.person = person;
}
public void eat() {
person.eat();
}
}
ConcreteDectrator 想组建添加职责
public class ManDecoratorA extends Decorator {
public void eat() {
super.eat();
reEat();
System.out.println("ManDecoratorA类");
}
public void reEat() {
System.out.println("再吃一顿饭");
}
}
public class ManDecoratorB extends Decorator {
public void eat() {
super.eat();
System.out.println("===============");
System.out.println("ManDecoratorB类");
}
}
Test
public class Test {
public static void main(String[] args) {
Man man = new Man();
ManDecoratorA md1 = new ManDecoratorA();
ManDecoratorB md2 = new ManDecoratorB();
md1.setPerson(man);
md2.setPerson(md1);
md2.eat();
}
}
result
男人在吃
再吃一顿饭
ManDecoratorA类
===============
ManDecoratorB类
发表评论
-
模板方法模式
2013-06-27 10:28 424引用http://eneasy.iteye.com/blog/ ... -
状态模式
2013-06-26 16:38 547引用http://blog.csdn.net/hguisu/a ... -
策略模式
2013-06-24 18:28 575定义 策略模式(Strategy)属于对象行为型设计模式,主要 ... -
代理模式-动态代理
2013-06-20 16:37 494转自:http://www.cnblogs.com/jqyp/ ... -
观察者模式-JDK支持
2013-06-18 14:39 417JDK对观察者模式的支持主要是通过Observable类和Ob ... -
观察者模式
2013-06-18 13:31 375GoF说道:Observer模式的意图是“定义对象间的一种一对 ... -
备忘录模式
2013-06-14 15:45 386转载:http://blog.csdn.net/m136663 ... -
java 中介者模式
2013-06-07 16:19 594定义:用一个中介者对象封装一系列的对象交互,中介者使各对象不需 ... -
迭代器模式
2013-06-07 11:18 653定义:提供一种方法访 ... -
命令模式
2013-06-05 16:56 760定义 将一个请求封装为 ... -
责任链模式
2013-06-03 16:46 571转自:《深入浅出设计 ... -
代理模式
2013-05-27 11:07 432一、简介 代理模式有两 ... -
享元模式
2013-05-23 16:43 530一、引子 让我们先来复习下 java 中String 类型的特 ... -
门面模式
2013-05-21 15:28 425转自http://www.cnblogs.com/java-m ... -
组合模式
2013-05-20 16:21 704一、引子 在大学的数据 ... -
桥接模式
2013-05-10 11:05 605认识桥接模式 (1)什么是桥接 在桥接模式里面 ... -
适配器模式
2013-05-08 14:04 6271. 概述 将一个类的接口转换成客户希望的另外一个接口 ... -
原型模式
2013-04-22 14:53 644转自:http://blog.csdn.net/zhengzh ... -
单态模式
2013-04-22 14:24 602保证一个类仅有一个实例,*提供一个访问它的全局访*点。 适 ... -
建造者模式
2013-04-18 10:27 635转自:http://www.2cto.com/kf/20120 ...
相关推荐
### 开发模式之装饰模式详解 #### 装饰模式定义 装饰模式(Decorator Pattern)是一种结构型设计模式,允许向对象动态地添加新的功能,而无需修改其原有结构。这种模式通过创建一个新的包装类来包裹真实的对象,...
装饰模式是一种设计模式,它允许我们在不修改原有对象的基础上,通过添加新的行为或属性来扩展对象的功能。在"装饰模式小猪快跑游戏模拟"这个实例中,我们看到这种模式被巧妙地应用到了一个名为“小猪吃苹果”的游戏...
装饰模式是一种结构型设计模式,它允许我们向一个对象动态地添加新的行为或责任,而无需修改该对象的源代码。在C#中,装饰模式是通过创建一个包装类(Decorator),该包装类实现了与被装饰对象相同的接口,并持有被...
【装饰模式】是一种设计模式,源自Erich Gamma等人编写的《设计模式:可重用面向对象软件的基础》一书。这种模式在Swing开发中尤为常见,用于增强或改进现有对象的功能,尤其在Web应用程序中,如Java的J2EE环境,...
装饰模式是一种设计模式,属于结构型模式,其主要目的是在不改变对象本身的基础上,通过向对象添加新的行为或属性来扩展其功能。这种模式遵循“开闭原则”,即对扩展开放,对修改关闭。 在装饰模式中,有四个关键...
装饰模式是一种结构型设计模式,它允许在运行时给对象添加新的行为或责任,而无需修改对象的源代码。在Java中,装饰模式通常通过继承和组合来实现,提供了比子类化更灵活的方式来扩展对象的功能。 装饰模式的核心...
装饰模式是一种结构型设计模式,它允许在运行时向对象添加新的行为或责任,而无需修改对象的源代码。这种模式在软件工程中非常常见,因为它提供了灵活性,使得我们可以独立于对象的组合来扩展功能。 在C++中,装饰...
装饰模式是一种结构型设计模式,它允许在运行时动态地给对象添加新的行为或属性,而不必修改原有类的代码。这种模式的核心在于装饰者和组件接口的统一,使得装饰者可以替代原对象并添加额外的功能。在"设计模式之...
装饰模式(Decorator)是软件设计领域中一种非常实用的结构型设计模式,它允许我们向一个对象添加新的行为或责任,而无需修改该对象的源代码。在C++编程语言中,装饰模式常用于动态地扩展类的功能,使得类的行为在...
装饰模式是一种设计模式,它允许在运行时向对象添加新的行为或责任,而无需修改对象的源代码。这种模式在不违背开闭原则(对扩展开放,对修改关闭)的前提下,提供了灵活的扩展机制。装饰模式通常用于为已有对象添加...
装饰模式(Decorator Pattern)是设计模式中的一种结构型模式,它在不改变原有对象的基础上,通过添加额外的职责来扩展对象的功能。在C#中,装饰模式尤其适用于那些需要动态地增加或减少对象功能的情况,避免了使用...
装饰模式是一种设计模式,它允许在不改变对象自身的情况下,动态地给对象添加新的行为或职责。这种模式常用于在不修改源代码的情况下扩展对象的功能,或者为对象提供额外的职责。在本例中,"项目经理接到一个项目,...
装饰模式是一种设计模式,它允许我们在不改变对象本身的情况下,为对象添加新的行为或属性,从而扩展其功能。这种模式遵循“开闭原则”,即对扩展开放,对修改关闭,这意味着我们可以灵活地增加一个对象的功能,而...
装饰模式是一种结构型设计模式,它允许我们向现有的对象添加新的功能,同时又不破坏其原有的结构。在C#中,装饰模式常用于在运行时动态地改变对象的行为,而无需修改原始类的代码。这种模式的核心在于装饰者类与被...
装饰模式是一种设计模式,它允许在运行时向对象添加新的行为或职责,而无需修改对象的源代码。这种模式在软件工程中非常有用,因为它提供了灵活性,使得代码可以在不破坏封装性的前提下进行扩展。 在"实验九:装饰...
装饰模式是一种设计模式,它允许在不修改对象本身的情况下,通过包装(或“装饰”)对象来动态地扩展其功能。在面向切面编程(Aspect Oriented Programming, AOP)中,装饰模式常被用来实现在运行时向目标对象添加...
装饰模式是一种结构型设计模式,它允许在运行时向对象添加新的行为或责任,而无需修改对象的源代码。这种模式通常用于保持对象的原始类结构不变,同时增强其功能。HeadFirst 设计模式系列书籍以其生动有趣的插图和...
装饰模式是一种结构型设计模式,它允许我们向对象添加新的行为或责任,而无需修改对象的源代码。这种模式在不违背开闭原则(对扩展开放,对修改关闭)的前提下,提供了灵活的扩展机制。在《Head First设计模式》一书...
装饰模式是一种结构型设计模式,它是面向对象设计中用来动态添加或修改对象功能的一种方法。在软件工程中,装饰模式允许我们向一个现有的对象添加新的行为或职责,同时又不改变其原有的结构,从而实现对类的功能扩展...
装饰模式是一种设计模式,它允许在运行时向对象添加新的行为或责任,而无需修改对象的源代码。这种模式在Java等面向对象编程语言中非常常见,因为它提供了灵活性,使得扩展对象的功能变得容易且优雅。在这个"装饰...