装饰模式比较简单,但是比较实用。可以在不用继承的情况下,扩展原有对象的功能。该模式简单明了,需要牢牢记住!
1. 装饰模式(Decorator)的定义:又名包装(Wrapper)模式,装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案。
2. 装饰模式以对客户端透明的方式动态的给一个对象附加上更多的责任。换言之客户端并不会觉的对象在装饰前和装饰后有什么区别。
3. 装饰模式可以在不创造更多的子类的模式下,将对象的功能加以扩展。
4.装饰模式的特点:1) 装饰对象和真实对象具有相同的接口,这样客户端对象就可以以真实对象的相同的方式和装饰对象交互。
2) 装饰对象包含一个真实对象的引用(reference).
3) 装饰对象接受所有来自客户端的请求,它把这些请求转发给真实的对象。
4) 装饰对象可以在转发这些请求以前或者以后增加一些附加的功能。这样就能确保在运行时,不用修改给定对象结构就可以在外部增加附加的功能。在面向对象的程序设计中,通常是使用继承的关系来扩展给定类的功能。
5。装饰模式与类继承的区别:1) 装饰模式是一种动态行为,对已经存在类进行随意组合,而类的继承是一种静态的行为,一个类定义成什么样的,该类的对象便具有什么样的功能,无法动态的改变。
2) 装饰模式扩展的是对象的功能,不需要增加类的数量,而类继承扩展是类的功能,在继承的关系中,如果我们想增加一个对象的功能,我们只能通过继承关系,在子类中增加两个方法。
3) 装饰与继承比较图:
4) 装饰模式是在不改变原类文件和使用继承的情况下,动态的扩展一个对象的功能,它是通过创建一个包装对象,也就是装饰来包裹真是的对象。
6. 装饰模式把对客户端的调用委派给被装饰的类,装饰模式的关键在于这种扩展完全透明的。
7.装饰模式的构成:
1) 抽象构建角色(Component):给出一个抽象的接口,以规范准备接受附加责任的对象。相当于i/o流里面InputStream/OutputStream和Reader/Writer。
2) 具体的构建角色(ConcreteComponent):定义一个将要接受附加责任的类。相当于i/o里面的FileOutputStream和FileInputStream。
3) 装饰角色(Docorator):持有一个抽象构建(Component)角色的引用,并定义一个与抽象构件一致的接口。相当于i/o里面的FilerOutputStream和FilterInputStream。
4) 具体的装饰角色(ConcreteDecorator):负责给构建对象“贴上”附加的责任。相当于i/o流里面的BufferedOutputStream和BufferedInputStream以及DataOutputStream和DataInputSrtream
8.案例:
1) 抽象的构建接口:
packagecom.abao.decorate;
public interface Component
{
public void doSomething();
}
2) 具体的构建角色:
packagecom.abao.decorate;
public class ConcreteComponent implements Component
{
@Override
public void doSomething()
{
System.out.println("功能A");
}
}
3) 装饰角色:
packagecom.abao.decorate;
public class Decorate implements Component
{
private Component component;
public Decorate(Component component)
{
this.component = component;
}
@Override
public void doSomething()
{
component.doSomething();
}
}
4) 具体装饰角色1:
packagecom.abao.decorate;
public class ConcreteDecorate1 extends Decorate
{
public ConcreteDecorate1(Component component)
{
super(component);
}
@Override
public void doSomething()
{
super.doSomething();
this.doAnotherDosomething();
}
private void doAnotherDosomething()
{
System.out.println("功能B");
}
}
5) 具体装饰角色2:
packagecom.abao.decorate;
public class ConcreteDecorate2 extends Decorate
{
public ConcreteDecorate2(Component component)
{
super(component);
}
@Override
public void doSomething()
{
super.doSomething();
this.doAnotherDosomething();
}
private void doAnotherDosomething()
{
System.out.println("功能C");
}
}
6) 客户端
packagecom.abao.decorate;
public class Client
{
public static void main(String[] args)
{
Component component = new ConcreteDecorate1(
new ConcreteDecorate2(new ConcreteComponent()));
component.doSomething();
}
}
装饰者模式
动态地将责任附加到对象上。若要扩展功能,装饰者提供了比继承更有弹性的替代方案。
具体被装饰者和抽象装饰类都继承于抽象被装饰者类,继承的是类型,而不是行为。行为来自装饰者和基础组件,或与其他装饰者之间的组合关系。
装饰者通常是用其他类似于工厂或生成器这样的模式创建的。
具体例子
抽象被继承者类:Beverage.java
具体被装饰类:HouseBlend.java, DarkRoast.java, Decat.java, Espresso.java,只给出一个,其他类似
装饰者抽象类:CondimentDecorator.java
具体装饰者类:Mocha.java,Soy.java,Milk.java,Whip.java,只给出一个,其他类似
测试类:Test.java
要点总结
1)继承属于扩展形式之一,但不见得是达到弹性设计的最佳方式。
2)在设计中,应该允许行为可以被扩展,而无须修改现有的代码。
3)组合和委托可用于在运行时动态地加上新的行为。
4)除了继承,装饰者模式也可以让我们扩展行为。
5)装饰者模式意味着一群装饰者类,这些类用来包装具体组件。
6)装饰者类反映出被装饰的组件类型(事实上,他们具有相同的类型,都经过接口或继承实现)。
7)装饰者可以在被装饰者的行为前面与/或后面加上自己的行为,甚至将被装饰者的行为整个取代掉,而达到特定的目的。
8)可以用无数个装饰者包装一个组件。
9)装饰者一般对组件的客户是透明的,除非客户程序依赖于组件的具体类型。
10)装饰者会导致设计中出现许多小对象,如果过度使用,会让程序变得很复杂。