设计模式学习之路 - 装饰者模式 - 动态扩展器
2016-07-21 10:21
459 查看
今天了解下装饰者模式。
首先,看下需求。
一家咖啡厅需要做一个订单系统,为了配合他们的饮料供应需求。
首先有一个超类,饮料类。
他有一个属性,对饮料的描述,两个方法,一个方法是返回描述,另一个方法是抽象方法, 返回饮料的价钱。
然后我们开始做事了,创建一个实体类,比如摩卡咖啡,继承饮料类,然后加上相应的描述并且重写cost()方法就行了。
每一种饮料都写一个类去继承,比如蒸馏咖啡, 黑咖啡, 拿铁咖啡等等等等。。
好像看起来没有什么问题。
这时候,其他的需求就来了, 购买咖啡的时候,顾客可以要求向咖啡中加入各种调料, 比如蒸奶, 豆浆, 摩卡 或者奶泡等等。
然后我们开始不同的尝试。
第一种尝试:
按照上面的思路,我们对每一种不同的咖啡都创建一种新的类,去继承超类,然后通过返回不同的描述和价格,达到我们的目的。
比如:黑咖啡, 加蒸奶的黑咖啡,加摩卡的黑咖啡, 加蒸奶和摩卡的黑咖啡。。。。。等等等等。。。
这时候我们会发现一个问题了,通过不同的组合,我们必须要穷举所有的类型,才能把这个系统完善,这就要“类爆炸”了,现实中要维护这么多同种类是十分可怕而且愚蠢的。
由于第一种方案很low,我们开始考虑其他的方案
第二种尝试:
我们通过在超类中加属性,蒸奶,摩卡等等。。然后返回是否需要蒸奶,是否需要摩卡等方法。。
这样的话,通过设置不同的属性,我们可以定义出不同的饮料,只需要设置是否需要蒸奶,是否需要摩卡等字段就行了,再通过调料的选择计算价格。
这个方案好像是比上面理智点,只需要基本的饮料类了, 至少不会由于调料的增加再增加新的类。
但是仔细想想, 好像还是有什么不妥,如果再要加新的调料的话,我们还需要把这个超类属性和相应的方法也修改。
这就违背了设计模式的一个重要的原则:类应该对扩展开发,对修改关闭。
第三种尝试:
这里,我们就开始引入我们的装饰者模式。
为何叫装饰者呢,就是因为我们只需要建一个饮料的对象,就可以用不同的调料去装饰他,而且可以一层一层的装饰,
最后调用cost()方法,通过依赖委托将调料的价格动态的加上去。
如何理解呢,我们直接看代码吧,前面的超类已经有了,我就不重复贴代码了。
这里,我们需要加一个新的装饰者类---调料类,并且继承饮料类,他只有一个抽象方法。
我们先实现一种咖啡, 浓缩咖啡!
然后我们再实现一种具体的调料,摩卡!
调料的实现就比较关键了,在调料中,我们会有一个Beverage的属性,当传入某种饮料后,会预先处理这种饮料的方法,并返回当前饮料的最后价格。
这样的话,就把调料装饰了传入的饮料, 并且可以一层一层的装饰,并且返回最后的价格。
为了测试,我们再加入一种调料,奶泡!
下面,我们要点一杯浓缩咖啡,再点一杯加了摩卡和奶泡的浓缩咖啡!
再贴下测试结果咯, 钱应该算的清吧,算数应该没这么差吧。。
有木有很方便,一下让代码变的优雅起来。
这就是装饰者模式:动态的将责任附加到对象上,若要扩展功能,装饰者提供了比继承更有弹性的替代方案。
使用装饰者模式, 可以让我们不需要改变原有的代码就可以动态的扩展新的需求.
在JDK的源码中, FilterInputStream 和 BufferedInputStream 就是使用的装饰着模式,通过一层一层的装饰,将inputStream的功能丰富化.
首先,看下需求。
一家咖啡厅需要做一个订单系统,为了配合他们的饮料供应需求。
首先有一个超类,饮料类。
package com.chris.decorator; public abstract class Beverage { String description = "Unkown Beverage"; public String getDescription() { return description; } public abstract double cost(); }
他有一个属性,对饮料的描述,两个方法,一个方法是返回描述,另一个方法是抽象方法, 返回饮料的价钱。
然后我们开始做事了,创建一个实体类,比如摩卡咖啡,继承饮料类,然后加上相应的描述并且重写cost()方法就行了。
每一种饮料都写一个类去继承,比如蒸馏咖啡, 黑咖啡, 拿铁咖啡等等等等。。
好像看起来没有什么问题。
这时候,其他的需求就来了, 购买咖啡的时候,顾客可以要求向咖啡中加入各种调料, 比如蒸奶, 豆浆, 摩卡 或者奶泡等等。
然后我们开始不同的尝试。
第一种尝试:
按照上面的思路,我们对每一种不同的咖啡都创建一种新的类,去继承超类,然后通过返回不同的描述和价格,达到我们的目的。
比如:黑咖啡, 加蒸奶的黑咖啡,加摩卡的黑咖啡, 加蒸奶和摩卡的黑咖啡。。。。。等等等等。。。
这时候我们会发现一个问题了,通过不同的组合,我们必须要穷举所有的类型,才能把这个系统完善,这就要“类爆炸”了,现实中要维护这么多同种类是十分可怕而且愚蠢的。
由于第一种方案很low,我们开始考虑其他的方案
第二种尝试:
我们通过在超类中加属性,蒸奶,摩卡等等。。然后返回是否需要蒸奶,是否需要摩卡等方法。。
这样的话,通过设置不同的属性,我们可以定义出不同的饮料,只需要设置是否需要蒸奶,是否需要摩卡等字段就行了,再通过调料的选择计算价格。
这个方案好像是比上面理智点,只需要基本的饮料类了, 至少不会由于调料的增加再增加新的类。
但是仔细想想, 好像还是有什么不妥,如果再要加新的调料的话,我们还需要把这个超类属性和相应的方法也修改。
这就违背了设计模式的一个重要的原则:类应该对扩展开发,对修改关闭。
第三种尝试:
这里,我们就开始引入我们的装饰者模式。
为何叫装饰者呢,就是因为我们只需要建一个饮料的对象,就可以用不同的调料去装饰他,而且可以一层一层的装饰,
最后调用cost()方法,通过依赖委托将调料的价格动态的加上去。
如何理解呢,我们直接看代码吧,前面的超类已经有了,我就不重复贴代码了。
这里,我们需要加一个新的装饰者类---调料类,并且继承饮料类,他只有一个抽象方法。
package com.chris.decorator; public abstract class Condiment extends Beverage{ public abstract String getDescription(); }
我们先实现一种咖啡, 浓缩咖啡!
package com.chris.decorator; public class Espresso extends Beverage{ public Espresso() { description = "Espresso"; } @Override public double cost() { return 30; } }
然后我们再实现一种具体的调料,摩卡!
package com.chris.decorator; public class Mocha extends Condiment{ Beverage beverage; public Mocha(Beverage beverage) { this.beverage = beverage; } @Override public String getDescription() { return beverage.getDescription() + " add Mocha"; } @Override public double cost() { return beverage.cost() + 3; } }
调料的实现就比较关键了,在调料中,我们会有一个Beverage的属性,当传入某种饮料后,会预先处理这种饮料的方法,并返回当前饮料的最后价格。
这样的话,就把调料装饰了传入的饮料, 并且可以一层一层的装饰,并且返回最后的价格。
为了测试,我们再加入一种调料,奶泡!
package com.chris.decorator; public class Whip extends Condiment { Beverage beverage; public Whip(Beverage beverage) { this.beverage = beverage; } @Override public String getDescription() { return beverage.getDescription() + " add Whip"; } @Override public double cost() { return beverage.cost() + 5; } }
下面,我们要点一杯浓缩咖啡,再点一杯加了摩卡和奶泡的浓缩咖啡!
package com.chris.decorator; public class CoffeeTestDrive { public static void main(String[] args) { Beverage beverage1 = new Espresso(); System.out.println(beverage1.getDescription() + " ¥" + beverage1.cost()); Beverage beverage2 = new Espresso(); beverage2 = new Mocha(beverage2); beverage2 = new Whip(beverage2); System.out.println(beverage2.getDescription() + " ¥" + beverage2.cost()); } }
再贴下测试结果咯, 钱应该算的清吧,算数应该没这么差吧。。
Espresso ¥30.0 Espresso add Mocha add Whip ¥38.0
有木有很方便,一下让代码变的优雅起来。
这就是装饰者模式:动态的将责任附加到对象上,若要扩展功能,装饰者提供了比继承更有弹性的替代方案。
使用装饰者模式, 可以让我们不需要改变原有的代码就可以动态的扩展新的需求.
在JDK的源码中, FilterInputStream 和 BufferedInputStream 就是使用的装饰着模式,通过一层一层的装饰,将inputStream的功能丰富化.
相关文章推荐
- PropertyChangeListener简单理解
- 什么是设计模式
- 设计模式之创建型模式 - 特别的变量问题
- 七、设计模式——装饰模式
- 设计模式总结
- 设计模式之创建型模式
- 浅谈设计模式的学习
- Ruby设计模式编程之适配器模式实战攻略
- 实例讲解Ruby使用设计模式中的装饰器模式的方法
- 设计模式中的模板方法模式在Ruby中的应用实例两则
- Ruby设计模式编程中对外观模式的应用实例分析
- 实例解析Ruby设计模式编程中Strategy策略模式的使用
- Ruby中使用设计模式中的简单工厂模式和工厂方法模式
- Ruby使用设计模式中的代理模式与装饰模式的代码实例
- 详解组合模式的结构及其在Ruby设计模式编程中的运用
- C# 设计模式系列教程-建造者模式
- C#编程中使用设计模式中的原型模式的实例讲解
- 使用设计模式中的工厂方法模式进行C#编程的示例讲解
- 实例解析C#设计模式编程中简单工厂模式的使用