装饰者模式:动态的将责任附加到对象上。想要扩展功能,装饰者提供有别于继承的另一种选择。
举个例子:星巴兹咖啡(不是星巴克)
星巴兹扩张速度太快了,他们准备更新订单系统,以合乎他们的饮料供应要求。他们的要求是这样子的:购买咖啡时,可以要求在其中加入各种调料,例如:蒸奶(Steamed Milk)、豆浆(Soy)、摩卡(Mocha,也就是巧克力风味)或者覆盖奶泡。星巴兹会根据所加入的调料不同收取不同的费用。所以订单系统必须考虑到这些调料的部分。
先来进行第一次尝试:
哇塞!这简直是“类爆炸”!很明显,按照上面做出来的的系统同样创造了一个维护噩梦。如果调料Milk价格上涨,怎么办?新增加一种调料时,就会诞生多少种新的咖啡?造成这样维护上的困难,违背了我们的设计原则:多用组合,少用继承;要针对接口编程,而不是针对实现编程。
那我们就换一种方式,先从Beverage基类入手,加上实例变量代表是否加上调料(牛奶、豆浆、摩卡、奶泡、辣椒......)
现在加入子类,每个类代表一种饮料。
认真想一下上面的方法还是有一些潜在的问题。当哪些需求或因素改变时会影响这个设计?
1.当调料价格的改变会使我们更改现有代码。
2.一旦出现新的调料,我们就需要加上新的方法,并改变超类中的cost()方法。
3.以后可能会开发出新饮料。对这些饮料而言(例如:冰茶、绿豆沙冰),某些调料可能并不适合,但是在这个设计方式中,Tea子类仍将继承那些不适合的方法,例如:hasWhip() (加奶泡)。
4.万一顾客想要双倍牛奶咖啡,怎么办?
在此我们将介绍最重要的设计原则之一
类应该对扩展开放,对修改关闭(开放封闭原则)
现在我们介绍今天的主角:装扮者模式
以装饰者构造饮料订单
1.以DarkRoast对象开始
2.顾客想要摩卡(Mocha),所以建立一个Mocha对象,并用它将DarkRoast对象包装(wrap)起来。
3.顾客也想要奶泡(Whip),所以需要建立一个Whip装饰者,并用它将Mocha对象包装起来。别忘了,DarkRoast继承自Beverage,且有一个cost()方法,用来计算饮料价格。
4.顾客其实对奶泡情有独钟,所以点了双倍的奶泡.
5.现在该结账了
好了,这是目前我们了解的装饰者模式:
1.装饰者和被装饰者对象有相同的超类型。
2.你可以用一个或者多个装饰者包装一个对象。
3.在任何需要原始对象(被包装的)的场合,可以用装饰过的对象代替它。
4.装饰者可以在所委托被装饰者的行为之前或之后,加上自己的行为,以达到特定的目的。
5.对象可以在任何时候被装饰,所以在运行时动态地、不限量地使用你喜欢的装饰者来装饰对象,
定义装饰者模式:
动态的将责任附加到对象上。想要扩展功能,装饰者提供比继承更有弹性的替代方案。
我们来看一下类图:
星巴兹咖啡的类图:
现在写下星巴兹的代码:
先从Beverage类入手:
public abstract class Beverage { //Beverage是一个抽象类 String description = "Unknow Beverage"; public String getDescription() { //getDescription已经实现了,但是cost需要在子类中实现 return description; } public abstract double cost(); }
现在来实现Condiment(调料)抽象类,也就是装饰者类:
public abstract class CondimentDecorator extends Beverage { public abstract String getDescription();//所有的调料类都必须重新该方法 }
写饮料代码:
public class Espresso extends Beverage {//Espresso扩展自 Beverage public Espresso() { description = "Espresso";//设置饮料的描述 } public double cost(){ return 1.99;//返回Espresso的价格 } } public class HouseBlend extends Beverage {//HouseBlend扩展自 Beverage public HouseBlend(){ description ="HouseBlend";//设置饮料的描述 } public double cost(){ return 0.89;//返回HouseBlend的价格 } }
写调料代码:
public class Mocha extends CondimentDecorator {//Mocha扩展自 CondimentDecorator Beverage beverage;//用一个实例记录饮料,也就是被装饰者 public Mocha(Beverage beverage) {//让被装饰者(饮料)被记录到实例变量中 this.beverage = beverage; } public String getDescription() {//不仅仅描述饮料,同样可以将调料完整地显示出来 return beverage.getDescription()+" , Mocha"; } public double cost() { return 0.20 + beverage.cost();//返回带Mocha饮料的价钱 } }
测试代码:
public class StarbuzzCoffee { public static void Main (String args[]){ Beverage beverage = new Espresso(); System.out.println(beverage.getDescription() +" $"+beverage.cost()); Beverage beverage2 = new HouseBlend(); System.out.println(beverage2.getDescription() +" $"+beverage2.cost()); } }
真实世界的装饰者:Java I/O
装饰Java I/O类
但是Java I/O引用装饰者模式引发的一个“缺点”:利用装饰者模式,常常造成设计中有大量的小类,数量实在是太多,可能会造成使用此API程序员的困扰。
回首看一下我们设计箱内的工具:
OO基础: 抽象、封装、多态、继承
OO原则: 封装变化;多用组合,少用继承;针对接口编程,不针对实现编程;为交互对象之间松耦合设计而努力;对扩展开放,对修改关闭;
OO模式:
1.策略模式(定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化)
2.观察者模式(在对象之间定义一对多的依赖,这样一来,当一个对象改变状态,依赖它的对象都会收到通知,并自动更新)
3.装饰者模式(动态的将责任附加到对象上。想要扩展功能,装饰者提供有别于继承的另一种选择。)
作者: 伊甸一点
本文版权归作者伊甸一点和博客园所有,欢迎转载和商用(须保留此段声明),且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利.