Java设计模式透析--装饰者模式(二)
2017-05-28 09:24
417 查看
装饰者模式:动态地将责任附加到对象上。若要扩展功能,装饰者提供了比继承更有弹性的替代方案;
知识点的梳理:
装饰者模式符合开闭原则!
继承属于扩展形式之一,但不见得是达到弹性设计的最佳方式;
在我们的设计中,应该允许行为可以被扩展,而无须修改现在的代码;
组合和委托可用于在运行时动态地加上新的行为;
除了继承,装饰者模式也可以让我们扩展行为;
装饰者模式意味着一群装饰者类,这些类用来包装具体组件;
装饰者反映出装饰的组件类型(事实上,他们具有相同的类型,都经过接口或继承实现);
装饰者可以在委托被装饰者的行为之前与/或之后,加上自己的行为,以达到特定的目的;
装饰者会导致设计中出现许多小对象,如果过度使用,会让程序变得很复杂;
星巴兹的故事
案例需求:此咖啡店扩张速度极快,他们准备更新订单系统,已合乎他们的饮料供应要求;
他们原先的类设计是这样的:
![](https://img-blog.csdn.net/20170528092403848)
购买咖啡时,也可以要求在其中加入各种调料,例如豆浆,摩卡等等。星巴兹会根据加入的调料来收取不同的费用;
先来利用实例变量和继承来解决这些需求;
![](https://img-blog.csdn.net/20170528092405176)
此设计的问题:
调料价钱的改变会使我们更改现有代码;
一旦出现新的调料,我们就需要加上新的方法啊,并改变超类中的cost()方法;
以后可能会开发出新饮料。对于这些新产品,某些调料可能并不适合,但是在这个设计方式中,新产品类仍将继承那些不适合的方法,也就是调料;
万一顾客想要双倍摩卡咖啡,怎么办?
装饰者模式
看来第一版的设计不符合我们的需求。现在我们要以饮料为主体,然后在运行时以调料来"装饰"饮料。
比如,如果顾客想要摩卡和奶泡深焙咖啡,那么,要做的是:
拿一个深焙咖啡对象;
以摩卡对象装饰它;
以奶泡对象装饰它;
调用cost()方法,并依赖委托将调料的价钱加上去;
以装饰者构造饮料订单
以DarkRoast对象开始
![](https://img-blog.csdn.net/20170528092405720)
顾客想要摩卡,所以建立一个Mocha对象,并用它将DarkRoast对象包(wrap)起来
![](https://img-blog.csdn.net/20170528092406129)
顾客也想要奶泡,所以需要建立一个Whip装饰者,并用它将Mocha对象包起来。DarkRoast继承自Beverage,且有一个cost()方法,用来计算饮料价钱;
![](https://img-blog.csdn.net/20170528092406720)
现在,该是为顾客算钱的时候了。通过调用最外圈装饰者(Whip)的cost()就可以办得到。Whip的cost()会先委托它装饰的对象(也就是Mocha)计算出价钱,然后再加上奶泡的价钱;
![](https://img-blog.csdn.net/20170528092407442)
总结时间!
装饰者和被装饰对象有相同的超类型;
你可以用一个或多个装饰者包装一个对象;
既然装饰者和被装饰对象有相同的超类型,所以在任何需要原始对象(被包装的)的场合,可以用装饰过的对象代替它;
装饰者可以在委托被装饰者的行为之前与/或之后,加上自己的行为,以达到特定的目的;
对象可以在任何时候被装饰,所以可以在运行时动态地,不限量地用你喜欢的装饰者来装饰对象;
定义装饰者模式
根据以上论证,来看看装饰者模式下应该如何设计
![](https://img-blog.csdn.net/20170528092408611)
将此框架套入星巴兹的饮料系统
![](https://img-blog.csdn.net/20170528092409833)
CondimentDecorator扩展自Beverage类,用到了继承,我们不是要使用"组合"来取代"继承"吗?
这么做的重点在于,装饰者和被装饰者必须是一样的类型,也就是共同的超类,这很关键!
我们利用继承达到类型匹配,而不是利用继承获得"行为"!
装饰者需要和被装饰者有相同的"接口",因为装饰者必须能取代被装饰者。但是行为从哪里来呢?
将装饰者与组件组合时,就是加入新的行为。得到的新行为并不是继承自超类,而是由组合对象得来的!
如果我们需要继承的是component类型,为什么不将Beverage类设计成一个接口,而是设计成一个抽象类呢?
因为星巴兹的初始程序中,Beverage已经是一个抽象类了。我们应该尽量避免修改原始代码。
写下代码
先从Beverage类下手:
实现Condiment(调料)抽象类,也就是装饰者类:
编写饮料的代码,先从浓缩咖啡开始,我们需要为具体的饮料设置描述,而且还必须实现cost()方法:
调料的代码,也就是具体装饰者,先从摩卡开始:
我们还需要额外的具体装饰者Soy与Whip
是测试的时候了
问题
如果将代码针对特定种类的具体组件(例如:HouseBlend),做一些特殊的事(例如:打折),这样的设计是否恰当?因为一旦用装饰者包装HouseBlend,就会造成类型改变;
如果把代码写成依赖于具体的组件类型,那么装饰者就会导致程序出问题。只有针对抽象组件类型编程时,才不会因为装饰者而受到影响。但是,如果的确针对特定的具体组件编程,就应该重新思考该程序的应用架构了,以及装饰者是否合适;
对于使用到饮料的某些客户来说,会不会容易不使用最外圈的装饰者呢?比如,如果我有深焙咖啡,以摩卡,豆浆,奶泡来装饰,引用到豆浆而不是奶泡,代码会好写一些,这意味着订单里没有奶泡了;
当然可以说使用装饰者模式,必须管理更多的对象,所以犯下编码错误的机会也会增加。但是,装饰者通常是用其他类似于工厂或生成器这样的模式创建的。
真实世界的装饰者:Java I/O
I/O类中的许多设计都源自装饰者模式
下图是一个典型的对象集合,用装饰者来将功能结合起来,以读取文件数据;
![](https://img-blog.csdn.net/20170528092411611)
BufferedInputStream及LineNumberInputStream都扩展自FilterInputStream,而FilterInputStream是一个抽象的装饰类;
装饰java.io类
![](https://img-blog.csdn.net/20170528092412161)
java.io的设计,与星巴兹的设计差不多;
在java.io中,"输出"流的设计方式也是一样的。Reader/Writer和输入流/输出流的类相当类似;
但是,java.io也引出了装饰者模式的一个"缺点":会造成设计中大量的小类,数量实在太多;
编写自己的Java I/O
需求:编写一个装饰者,把输入流内的所有大写字符转成小写
只要扩展FilterInputStream类,并覆盖read()方法即可!
测试
test.txt要自己制作哦!
知识点的梳理:
装饰者模式符合开闭原则!
继承属于扩展形式之一,但不见得是达到弹性设计的最佳方式;
在我们的设计中,应该允许行为可以被扩展,而无须修改现在的代码;
组合和委托可用于在运行时动态地加上新的行为;
除了继承,装饰者模式也可以让我们扩展行为;
装饰者模式意味着一群装饰者类,这些类用来包装具体组件;
装饰者反映出装饰的组件类型(事实上,他们具有相同的类型,都经过接口或继承实现);
装饰者可以在委托被装饰者的行为之前与/或之后,加上自己的行为,以达到特定的目的;
装饰者会导致设计中出现许多小对象,如果过度使用,会让程序变得很复杂;
星巴兹的故事
案例需求:此咖啡店扩张速度极快,他们准备更新订单系统,已合乎他们的饮料供应要求;
他们原先的类设计是这样的:
购买咖啡时,也可以要求在其中加入各种调料,例如豆浆,摩卡等等。星巴兹会根据加入的调料来收取不同的费用;
先来利用实例变量和继承来解决这些需求;
为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(); } |
/* * 要让CondimentDecorator能够取代Beverage,所以将CondimentDecorator扩展自Beverage类 */ public abstract class CondimentDecorator extends Beverage { //所有调料装饰者都必须重新实现getDescription()方法 public abstract String getDescription(); } |
//让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(); } } |
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(); } } } |
相关文章推荐
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析--装饰者模式(二)
- Java设计模式透析之 —— 单例(Singleton)
- java设计模式---装饰者模式(简单笔记)
- [原]Java设计模式透析之 —— 适配器(Adapter)
- Java设计模式透析之 —— 策略(Strategy)
- Java设计模式透析之 —— 模板方法(Template Method)
- Java设计模式透析之 —— 适配器(Adapter)