装饰(Decorator)模式的定义:指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)的模式,它属于对象结构型模式。
装饰模式的结构与实现
通常情况下,扩展一个类的功能会使用继承方式来实现。但继承具有静态特征,耦合度高,并且随着扩展功能的增多,子类会很膨胀。如果使用组合关系来创建一个包装对象(即装饰对象)来包裹真实对象,并在保持真实对象的类结构不变的前提下,为其提供额外的功能,这就是装饰模式的目标。下面来分析其基本结构和实现方法。
- 模式的结构
装饰模式主要包含以下角色。 - 抽象构件(Component)角色:定义一个抽象接口以规范准备接收附加责任的对象。
- 具体构件(Concrete Component)角色:实现抽象构件,通过装饰角色为其添加一些职责。
- 抽象装饰(Decorator)角色:继承抽象构件,并包含具体构件的实例,可以通过其子类扩展具体构件的功能。
- 具体装饰(ConcreteDecorator)角色:实现抽象装饰的相关方法,并给具体构件对象添加附加的责任。
装饰者模式结构图
模式应用举例
- 抽象构件角色: 例如(鸟会叫,抽象构件是鸟类【是一个接口】)
- 具体构建角色: 实现鸟叫的方法
- 抽象装饰角色:就是要拓展鸟叫的方法,所以要继承抽象构件,同时里面有一个具体构件的实例(保留具体构件鸟叫的方法,在进行功能的增加。这个实例就是用来调鸟叫方法的)。
- 具体装饰角色:真正要增加的功能,例如这只鸟是鹦鹉会说人话
/**
*抽象角色
*
*/
public interface Bird {
void behavior();
}
/**
*
* 具体角色:抽象角色的基本实现
*
*/
public class TruelyBird implements Bird {
@Override
public void behavior() {
System.out.println("叽叽喳喳的叫");
}
/**
*抽象装饰
*
*/
public class SpeakingBird implements Bird {
private Bird speakBird;
public SpeakingBird(Bird bird) {
this.speakBird = bird;
}
@Override
public void behavior() {
speakBird.behavior();
}
}
/**
* 抽象装饰的具体实现一
*/
public class Yingwu extends SpeakingBird {
public Yingwu(Bird bird) {
super(bird);
}
@Override
public void behavior() {
super.behavior();
System.out.println("这是一只鹦鹉,不仅仅叽叽喳喳还会人话");
}
}
/**
*
* 抽象角色的具体实现二
*/
public class Bage extends SpeakingBird {
public Bage(Bird bird) {
super(bird);
}
public void sayHi() {
System.out.println("早安,晚安");
}
@Override
public void behavior() {
super.behavior();
sayHi();
}
}
//测试
public static void main(String[] args) {
Yingwu yingwu = new Yingwu(new TruelyBird());
yingwu.behavior();
System.out.println("********************************分割线*********************************");
Bage bage = new Bage(new TruelyBird());
bage.behavior();
}
总结
装饰模式的应用场景
前面讲解了关于装饰模式的结构与特点,下面介绍其适用的应用场景,装饰模式通常在以下几种情况使用。
- 当需要给一个现有类添加附加职责,而又不能采用生成子类的方法进行扩充时。例如,该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。
- 当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时,采用继承关系很难实现,而采用装饰模式却很好实现。
- 当对象的功能要求可以动态地添加,也可以再动态地撤销时。
装饰(Decorator)模式的主要优点有:
- 采用装饰模式扩展对象的功能比采用继承方式更加灵活。
- 可以设计出多个不同的具体装饰类,创造出多个不同行为的组合。
其主要缺点是:装饰模式增加了许多子类,如果过度使用会使程序变得很复杂。
疑惑:
为什么要抽象出一个单独的抽象装饰呢(SpeakingBird ),直接去用抽象角色的具体实现(TruelyBird)不行吗?