设计模式之装饰模式
设计模式之装饰模式
装饰模式非常强调实现技巧,我们一般用它应对类体系快速膨胀的情况。
在项目中,是什么原因导致类型体系会快速膨胀呢?在多数情况下是因为我们经常要为类型增加新的职责(功能),尤其在软件开发和维护阶段,这方面需求更为普遍。
面向对象中每一个接口代表我们看待对象的一个特定方面。在Java编码实现过程中由于受到单继承的约束,我们通常也会将期望扩展的功能定义为新的接口,进而随着接口不断增加,实现这些接口的子类也在快速膨胀,如新增3个接口的实现,就需要8个类型(包括MobileImpl),4个接口则是16个类型,这种几何基数的增长我们承受不了。为了避免出现这种情况,之前我们会考虑采用组合接口的方式解决,但客户程序又需要从不同角度看待组合后的类型,也就是可以根据里氏替换原则用某个接口调用这个子类。所以面临的问题是,既要has a、又要is a,装饰模式解决的就是这类问题。
经典回顾
装饰模式的意图非常明确:动态为对象增加新的职责。
这里有两个关键词:动态和增加,也就是说,这些新增的功能不是直接从父类继承或是硬编码写进去的,而是在运行过程中通过某种方式动态组装上去的。例如:我们在录入文字的时候,最初只需要一个Notepad功能的软件,然后增加了很多需求:
字体可以加粗。
文字可以显示为不同颜色。
字号可以调整。
字间距可以调整。
……
不仅如此,到底如何使用这些新加功能,需要在客户使用过程中进行选择,也就是说,新的职责(功能或成员)是需要动态增加的。为了解决这类问题,装饰模式给出的解决方案如图12-1所示。
根据Notepad的示例要求,设计如图12-2所示的静态结构。
首先,我们需要的是显示文字,这时可以指定一个名为Text的接口,它有名为Content的读/写属性。
然后,我们把所有需要用来装饰的类型抽象出一个名为Decorator的接口,它继承自这个Text,因此其实体类必须实现Content属性方法。
接着,我们把没有任何新增功能的Text做出一个“毛坯”的实体类型,命名为TextImpl。
最后,我们把操作字体bold()、setColor()的方法填充到每个具体的装饰类型中。
这样,概念上当TextImpl需要某种新增功能时,直接为其套上某个具体装饰类型就可以了。这就好像给TextImpl类穿上一层又一层的“马甲”。该模式这么做主要是为了适用于哪些情景呢?
在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责。
毕竟客户程序依赖的仅仅是Component接口,至于这个接口被做过什么装饰,只有实施装饰的对象才知道,而客户程序只是依据Component的接口方法调用它,这样,装饰类在给Component穿上新“马甲”的同时也会随着客户程序的调用一并执行了。
屏蔽某些职责,也就是在套用某个装饰类型时,并不增加新的特征,只把既有方法屏蔽。
也就是说,装饰类不仅能否充当“马甲”,也能起到“口罩”的作用,让Component现有的某些方法“闭嘴”。尽管我们使用装饰模式一般是为了增加功能(做“加法”),但并不排斥它也具有方法屏蔽的作用(做“减法”),只不过平时用的比较少而已。
避免因不断调整职责导致类型快速膨胀的情况。
下面看一段示例代码:
Java 抽象部分
public
interface Text {
String getContent();
void setContent(String content);
}
/**
implements Text 说明Decorator
is a Text*/
public
class Decorator
implements Text{
/** 构造方式注入has a的text接口 */
private Text text;
public Decorator(Text text){
this.text = text;
}
@Override
public String getContent(){
return text.getContent();
}
@Override
public void setContent(String content){
text.setContent(content);
}
}
Java 具体装饰类型
/**
* 具体装饰类,属于“马甲”
*/
class BoldDecorator extends Decorator{
public BoldDecorator(Text text){
super(text);
}
public String bold(String data){
return "<b>" + data +
"</b>";
}
@Override
public String getContent() {
return bold(super.getContent());
}
@Override
public void setContent(String
content) {
super.setContent(content);
}
}
/**
* 具体装饰类
* 属于“马甲”
*/
class ColorDecorator extends Decorator{
public ColorDecorator(Text text){
super(text);
}
public String setColor(String data){
return "<color>" + data +
"</color>";
}
@Override
public String getContent() {
return setColor(super.getContent());
}
@Override
public void setContent(String
content) {
super.setContent(content);
}
}
/**
* 具体装饰类
* 属于“口罩”
*/
class BlockAllDecorator extends Decorator{
public BlockAllDecorator (Text text){
super(text);
}
@Override
public String getContent() {
return null;
}
@Override
public void setContent(String
content) {
super.setContent(content);
}
}
Unit Test
Text
text;
@Before
public void setUp(){
text = new TextImpl();
}
/**
验证套用单个装饰对象的效果
*/
@Test
public void testSingleDecorator(){
text = new Decorator(text);
//下面开始套用装饰模式,开始给text穿“马甲”
text = new BoldDecorator(text);
text.setContent("H");
assertEquals("<b>H</b>",
text.getContent());
}
/**
验证套用多个装饰对象的效果
*/
@Test
public void testMultipleDecorators(){
text = new Decorator(text);
//下面开始套用装饰模式,开始给text穿“马甲”
text = new BoldDecorator(text);
text = new ColorDecorator(text);
text = new BoldDecorator(text);
text.setContent("H");
assertEquals("<b><color><b>H</b></color></b>",text.getContent());
}
/**
验证装饰类型的撤销(/“口罩”)效果*/
@Test
public void testBlockEffectDecorator(){
text = new Decorator(text);
//下面开始套用装饰模式,开始给text穿“马甲”
text = new BoldDecorator(text);
text = new ColorDecorator(text);
text.setContent("H");
assertEquals("<color><b>H</b></color>",
text.getContent());
//下面开始套用装饰模式,开始给text戴“口罩”
text = new BlockAllDecorator(text);
assertNull(text.getContent());
}
从上面的示例中不难看出,装饰模式实现上特别有技巧,也很“八股”,它的声明要实现Component定义的方法,但同时也会保留一个对Component的引用,Component接口方法的实现其实是通过自己保存的Component成员完成的,而装饰类只是在这个基础上增加一些额外的处理。而且,使用装饰模式不仅仅是为了“增加”新的功能,有时候我们也用它“撤销”某些功能。项目中我们有3个要点必须把握:
Component不要直接或间接地使用Decorator,因为它不应该知道Decorator的存在,装饰模式的要义在于通过外部has a + is a的方式对目标类型进行扩展,对于待装饰对象本身不应有太多要求。
Decorator也仅仅认识Component。抽象依赖于抽象、知识最少。
某个ConcreteDecorator最好也不知道ComponentImpl的存在,因为ConcreteDecorator只能服务于这个ComponentImpl(及其子类)。
此外,使用装饰模式解决一些难题的同时,我们也要看到这个模式的缺点:
开发阶段需要编写很多ConcreteDecorator类型。
运行时动态组装带来的结果就是排查故障比较困难,从实际角度看,Component提交给客户程序的是最外层ConcreteDecorator的类型,但它的执行过程是一系列ConcreteDecorator处理后的结果,追踪和调试相对困难。
在实际项目中,我们往往会将一些通用的功能做成装饰类型单独编译,而且一般也鼓励这么做,因为可以减少重复开发,但这样会人为增加排查和调试的难度。好在反编译Java byte code不是太难。
本文节选自《模式——工程化实现及扩展(设计模式Java 版)》一书。
本书详细信息:
http://blog.csdn.net/broadview2006/article/details/7450002