假设我们要设计一个咖啡厅的订单系统,咖啡厅有四种类型的咖啡(饮料类型,浓度等区分,与配料无关,每种咖啡可以自由加入任何数量任何种类的配料),以及多种配料。我们需要实现的是根据客户订单,计算具体咖啡的价钱。
Several Method
使用继承
当对于每种具体的咖啡建立一个类时,类数量会迅速增长。配料价格的变化将会需要改变所有这些具体类。
改进的一种方法是,不再对于每个具体咖啡建立类,而是设置为配料变量,这样对于具体咖啡可以通过设置具体的变量实现。仍然存在的问题是,当调料的价格变化时,出现新的调料时等情况,我们仍然需要修改现有代码。
装饰器模式
在策略模式中,我们其实已经尝试实现这个重要的原则:开闭原则。
类应该对扩展开放,对修改关闭。
需要注意的是,我们并不需要也不可能将每个部分实现为满足开闭原则,而只是对设计中最有可能改变的地方应用开闭原则。
上面的例子已经显式,利用继承无法完全解决问题:类数量爆炸、设计死板,以及基类加入的新功能并不适用于所有的子类。
这里的问题我们可以使用装饰器模式:以饮料为主体,然后在运行时以调料在装饰饮料。比如说如果顾客想要摩卡加牛奶深焙咖啡,需要做的是:
- 建立一个深焙咖啡对象
- 以摩卡对象装饰上一个对象,建立摩卡对象
- 以牛奶(Whip)装饰上一个对象
- 调用cost()方法,并依赖委托上一个对象将前面的价格加上去。
装饰器模式
装饰器模式动态的将责任附加到对象上。如果要扩展功能,装饰者提供了比继承更有弹性的替代方案。装饰者可以在被委托的被装饰者的行为之前/之后,加上自己行为,以达到特定的目的。
另外,需要说明的几点是:
- 装饰者和被装饰对象有相同的超类型。
- 可以使用一个或多个装饰者包装一个对象。
- 装饰者和被装饰对象具有相同的父类,也就是装饰者可以进一步被其他装饰者包装,并且这一过程不限数量。
使用装饰器实现咖啡订单系统:
1 | public abstract class Beverage { |
1 | public class Espresso extends Beverage { |
1 | public class Mocha extends CondimentDecorator { |
使用装饰器模式:
1 | public class StarbuzzCoffee { |
Java I/O中很多类即采用了装饰器模型,将功能结合起来,实现更强大的读取数据或其他操作。