beverage

定义 装饰者模式动态地将责任责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。 实现要点 装饰器与被装饰的类需要继承自相同接口，来达到类型匹配。装饰器持有被装饰的类的实例。 代码实例 /** * 基础组件 */ abstract class Beverage { private String description = "Unknown Beverage"; public String getDescription() { return description; } public void setDescription(String description) { this.description = description; } public abstract double cost(); } /** * 装饰器基类 */ abstract class Decorator extends Beverage { @Override public abstract String getDescription(); } /** * 被装饰的类 */ class Espresso extends Beverage { public Espresso() { setDescription("Espresso"); } @Override public double

装饰者模式 1. 定义 装饰者模式 动态的将责任附加到对象上。如要扩展功能，装饰者提供了比继承更有弹性的替代方案。 2. 类图 3. Example 假如有这样一个需求：有一天，奶茶店的老板喊你给他们做一个简单版的计算价格程序。新店开张，供应的饮料有奶茶（8元）、红茶（7元）、绿茶（5元）三种，提供的配料有波霸1元，布丁5元，红豆3元。 则可如下设计： Component及其实现如下： package com.gitlearning.hanldegit.patterns.decorator; /** * 相当于Component */ public abstract class Beverage { String description = "Unkown beverage"; public String getDescription() { return description; } public abstract double cost(); } class MilkTea extends Beverage { @Override public String getDescription() { return "奶茶"; } @Override public double cost() { return 8.00; } } class RedTea extends

首先让我们看一下装饰者模式（我爱叫他套娃模式）的概念：动态的将责任附加到对象上， 若要扩展功能，装饰者 提供了比继承者更有弹性的集成方案。 什么？没看懂？没关系，最后再来看这个概念，想让让我们来看一个咖啡屋项目（就是点各式 各样的咖啡）。 原本的设计如下： 看似很好的设计，但是别忘了，买咖啡时候我们会让他们给我们加一系列的调料，例如蒸奶、 摩卡......。所以，在这时咖啡店的设计就变成了，如下： 不错，你看到了 类爆炸 ！ 好啦，现在有对这个系统做出了改进，如下： 好啦，现在这个设计相比之前的的确好了许多，但是如果我们要修改配料呢？那么就必须修改 超类，这时候就违反了一条 设计原则：类应该对扩展开放，对修改关闭 ！ 所以这个时候，装饰者模式单诞生了！！！！！ 来看个例子： 如果顾客现在要一杯摩卡和奶泡深培咖啡。那么，要做的是： ①拿一个深培咖啡（DarkRoast）对象 ②以摩卡（Mocha）对象装饰它 ③以奶泡（Whip）装饰它 ④调用cost()方法，并依赖委托（delegate）将调料的几千加上去 如何工作？ ①以DarkRoast对象开始 ②顾客想要摩卡（Mocha）,所以建立一个Mocha对象，并用它将DarkRoast对象包起来 ③顾客也想要奶泡（Whip）,所以建立一个Whip装饰者，并用它将Mocha对象包起来。别 忘了，DarkRoast继承自Beverage