Java设计模式透析--装饰者模式(二)
装饰者模式:动态地将责任附加到对象上。若要扩展功能,装饰者提供了比继承更有弹性的替代方案;
知识点的梳理:
- 装饰者模式符合开闭原则!
- 继承属于扩展形式之一,但不见得是达到弹性设计的最佳方式;
- 在我们的设计中,应该允许行为可以被扩展,而无须修改现在的代码;
- 组合和委托可用于在运行时动态地加上新的行为;
- 除了继承,装饰者模式也可以让我们扩展行为;
- 装饰者模式意味着一群装饰者类,这些类用来包装具体组件;
- 装饰者反映出装饰的组件类型(事实上,他们具有相同的类型,都经过接口或继承实现);
- 装饰者可以在委托被装饰者的行为之前与/或之后,加上自己的行为,以达到特定的目的;
-
装饰者会导致设计中出现许多小对象,如果过度使用,会让程序变得很复杂;
-
星巴兹的故事
-
案例需求:此咖啡店扩张速度极快,他们准备更新订单系统,已合乎他们的饮料供应要求;
-
他们原先的类设计是这样的:
- 购买咖啡时,也可以要求在其中加入各种调料,例如豆浆,摩卡等等。星巴兹会根据加入的调料来收取不同的费用;
-
- 先来利用实例变量和继承来解决这些需求;
-
为Beverage类加上实例变量,代表是否加上调料 |
-
此设计的问题:
- 调料价钱的改变会使我们更改现有代码;
- 一旦出现新的调料,我们就需要加上新的方法啊,并改变超类中的cost()方法;
- 以后可能会开发出新饮料。对于这些新产品,某些调料可能并不适合,但是在这个设计方式中,新产品类仍将继承那些不适合的方法,也就是调料;
- 万一顾客想要双倍摩卡咖啡,怎么办?
-
装饰者模式
-
看来第一版的设计不符合我们的需求。现在我们要以饮料为主体,然后在运行时以调料来"装饰"饮料。
-
比如,如果顾客想要摩卡和奶泡深焙咖啡,那么,要做的是:
- 拿一个深焙咖啡对象;
- 以摩卡对象装饰它;
- 以奶泡对象装饰它;
- 调用cost()方法,并依赖委托将调料的价钱加上去;
-
-
以装饰者构造饮料订单
-
以DarkRoast对象开始
-
顾客想要摩卡,所以建立一个Mocha对象,并用它将DarkRoast对象包(wrap)起来
-
顾客也想要奶泡,所以需要建立一个Whip装饰者,并用它将Mocha对象包起来。DarkRoast继承自Beverage,且有一个cost()方法,用来计算饮料价钱;
-
现在,该是为顾客算钱的时候了。通过调用最外圈装饰者(Whip)的cost()就可以办得到。Whip的cost()会先委托它装饰的对象(也就是Mocha)计算出价钱,然后再加上奶泡的价钱;
-
总结时间!
- 装饰者和被装饰对象有相同的超类型;
- 你可以用一个或多个装饰者包装一个对象;
- 既然装饰者和被装饰对象有相同的超类型,所以在任何需要原始对象(被包装的)的场合,可以用装饰过的对象代替它;
- 装饰者可以在委托被装饰者的行为之前与/或之后,加上自己的行为,以达到特定的目的;
- 对象可以在任何时候被装饰,所以可以在运行时动态地,不限量地用你喜欢的装饰者来装饰对象;
-
-
定义装饰者模式
-
根据以上论证,来看看装饰者模式下应该如何设计
-
-
将此框架套入星巴兹的饮料系统
-
CondimentDecorator扩展自Beverage类,用到了继承,我们不是要使用"组合"来取代"继承"吗?
- 这么做的重点在于,装饰者和被装饰者必须是一样的类型,也就是共同的超类,这很关键!
- 我们利用继承达到类型匹配,而不是利用继承获得"行为"!
-
装饰者需要和被装饰者有相同的"接口",因为装饰者必须能取代被装饰者。但是行为从哪里来呢?
- 将装饰者与组件组合时,就是加入新的行为。得到的新行为并不是继承自超类,而是由组合对象得来的!
-
如果我们需要继承的是component类型,为什么不将Beverage类设计成一个接口,而是设计成一个抽象类呢?
- 因为星巴兹的初始程序中,Beverage已经是一个抽象类了。我们应该尽量避免修改原始代码。
-
写下代码
- 先从Beverage类下手:
-
/** * Beverage是一个抽象类 */ public abstract class Beverage { String description = "Unknown Beverage"; /** * getDescription()已经在此实现了,但是cost()必须在子类中实现 */ public String getDescription(){ return description; } public abstract double cost(); } |
- 实现Condiment(调料)抽象类,也就是装饰者类:
/* * 要让CondimentDecorator能够取代Beverage,所以将CondimentDecorator扩展自Beverage类 */ public abstract class CondimentDecorator extends Beverage { //所有调料装饰者都必须重新实现getDescription()方法 public abstract String getDescription(); } |
- 编写饮料的代码,先从浓缩咖啡开始,我们需要为具体的饮料设置描述,而且还必须实现cost()方法:
//让Espresso扩展自Beverage类,因为Espresso是一种饮料 public class Espresso extends Beverage { //这个构造器用来设置饮料的描述。记住,description实例变量继承自Beverage public Espresso(){ description = "Espresso"; } @Override public double cost() { //计算Espresso的价钱,先直接返回一个数字 return 1.99; } } |
//另外一种饮料 public class HouseBlend extends Beverage { public HouseBlend(){ description = "House Blend coffee"; } @Override public double cost() { return 0.89; } } |
- 调料的代码,也就是具体装饰者,先从摩卡开始:
/** * 摩卡是一个装饰者,所以让它扩展自CondimentDecorator * CondimentDecorator扩展自Beverage */ public class Mocha extends CondimentDecorator { /** * 要让Mocha能够引用一个Beverage,做法如下: * 1.用一个实例变量记录饮料,也就是被装饰者; * 2.想办法让被装饰者(饮料)被记录到实例变量中。这里的做法是:把饮料当作构造器的参数,再由构造器将此饮料记录在实例变量中; */ Beverage beverage; public Mocha(Beverage beverage){ this.beverage = beverage; } /* * 我们希望叙述不只是描述饮料(如:"DarkRoast"),而是完整地连调料都描述出来(如:"DarkRoast,Mocha"); * 所以首先利用委托的做法,得到一个叙述,然后在其后加上附加的叙述(例如:"Mocha") */ @Override public String getDescription() { return beverage.getDescription() + ", Mocha"; }
@Override public double cost() { //计算带mocha饮料的价钱,首先把调用委托给被装饰对象,以计算价钱,然后在加上Mocha的价钱,得到最后结果 return 0.20 + beverage.cost(); } } |
- 我们还需要额外的具体装饰者Soy与Whip
public class Soy extends CondimentDecorator { Beverage beverage; public Soy(Beverage beverage){ this.beverage = beverage; } @Override public String getDescription() { return beverage.getDescription() + ", Soy"; }
@Override public double cost() { return 0.10 + beverage.cost(); } } |
public class Whip extends CondimentDecorator { Beverage beverage; public Whip(Beverage beverage){ this.beverage = beverage; } @Override public String getDescription() { return beverage.getDescription() + ", Whip"; }
@Override public double cost() { return beverage.cost(); } } |
- 是测试的时候了
public class StarbuzzCoffee { public static void main(String[] args) { Beverage beverage = new Espresso(); //订一杯Espresso,不需要调料,打印出它的描述与价钱 System.out.println(beverage.getDescription() + "$" + beverage.cost()); //再来一杯调料为豆浆,摩卡,奶泡的HouseBlend咖啡 Beverage beverage2 = new HouseBlend(); beverage2 = new Soy(beverage2); beverage2 = new Mocha(beverage2); beverage2 = new Whip(beverage2); System.out.println(beverage2.getDescription() + " $" + beverage2.cost()); } } |
效果: Espresso$1.99 House Blend coffee, Soy, Mocha, Whip $1.19 |
-
问题
-
如果将代码针对特定种类的具体组件(例如:HouseBlend),做一些特殊的事(例如:打折),这样的设计是否恰当?因为一旦用装饰者包装HouseBlend,就会造成类型改变;
- 如果把代码写成依赖于具体的组件类型,那么装饰者就会导致程序出问题。只有针对抽象组件类型编程时,才不会因为装饰者而受到影响。但是,如果的确针对特定的具体组件编程,就应该重新思考该程序的应用架构了,以及装饰者是否合适;
-
对于使用到饮料的某些客户来说,会不会容易不使用最外圈的装饰者呢?比如,如果我有深焙咖啡,以摩卡,豆浆,奶泡来装饰,引用到豆浆而不是奶泡,代码会好写一些,这意味着订单里没有奶泡了;
- 当然可以说使用装饰者模式,必须管理更多的对象,所以犯下编码错误的机会也会增加。但是,装饰者通常是用其他类似于工厂或生成器这样的模式创建的。
-
-
真实世界的装饰者:Java I/O
-
I/O类中的许多设计都源自装饰者模式
-
下图是一个典型的对象集合,用装饰者来将功能结合起来,以读取文件数据;
- BufferedInputStream及LineNumberInputStream都扩展自FilterInputStream,而FilterInputStream是一个抽象的装饰类;
-
-
装饰java.io类
- java.io的设计,与星巴兹的设计差不多;
- 在java.io中,"输出"流的设计方式也是一样的。Reader/Writer和输入流/输出流的类相当类似;
- 但是,java.io也引出了装饰者模式的一个"缺点":会造成设计中大量的小类,数量实在太多;
-
-
编写自己的Java I/O
-
需求:编写一个装饰者,把输入流内的所有大写字符转成小写
- 只要扩展FilterInputStream类,并覆盖read()方法即可!
-
import java.io.FilterInputStream; import java.io.IOException; import java.io.InputStream;
public class LowerCaseInputStream extends FilterInputStream { public LowerCaseInputStream(InputStream in){ super(in); } //针对字节 public int read() throws IOException{ int c = super.read(); return (c == -1 ? c : Character.toLowerCase((char)c)); } //针对字节数组 public int read(byte[] b,int offset, int len) throws IOException{ int result = super.read(b, offset, len); for (int i = offset; i < offset + result; i++) { b[i] = (byte)Character.toLowerCase((char)b[i]); } return result; } } |
- 测试
import java.io.BufferedInputStream; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.IOException; import java.io.InputStream;
public class InputTest { public static void main(String[] args) throws IOException { int c; try { InputStream in = new LowerCaseInputStream( new BufferedInputStream( new FileInputStream("test.txt"))); while((c = in.read()) >=0){ System.out.println((char)c); } in.close(); } catch (FileNotFoundException e) { e.printStackTrace(); } } } |
- test.txt要自己制作哦!