QY装饰模式.ppt

The Decorator Pattern（装饰模式） 实例背景 有这么一家咖啡连锁店，可以这样来形容其发展速度:如果今天在你吃午餐的小店边上有一家，明天在它的对面就会看到另一家。 关于咖啡的知识 咖啡种类 Houseblend:家常混合咖啡 Decaf:无咖啡因咖啡 Darkroast:黑咖（将咖啡豆深度烘培至接近暗黑） Espresso:，爱斯普利索咖啡(把粉末状的咖啡豆用蒸汽加压煮出来的浓咖啡)，意大利浓咖啡 Latte：拿铁（意大利浓缩咖啡与牛奶的经典混合） Cappuccino：卡布奇洛（在偏浓的咖啡上，倒入以蒸汽发泡的牛奶） 咖啡调料 Mocha:摩卡（巧克力） milk: Soy:豆奶 Whip:起泡牛奶(经过搅打使奶油起泡) 开发咖啡点单系统 因为生意兴隆，他们决定将其点单系统计算机化，以应付繁忙的业务需要。 开始时他们设计的类图如下： 初始类图 问题… 除了咖啡，客人还可以选择一些调味品。每种调味品都要收取一些费用，所以这些也应该包含在点单系统之内。他们想通过每个类的cost()方法来实现。 结果是。。。 类爆炸！！ 这显然是一个恶梦 试设想： 如果咖啡的价格发生变化 如果新出了一种咖啡调料 对系统开发人员来说意味着什么？ 怎么办？ 一种想法是，用实例变量和继承机制来解决各种调味品的问题 新方案中基类的类图 新设计方案的类图 基类的cost()代码应该是怎样的？ Public class Beverage { ... public double cost() { } ... } 子类的cost()代码应该是怎样的？ Public class DarkRoast extends Beverage { public DarkRoast() { description=“优质DarkRoast咖啡”; } public double cost() { } ... } 该方案有什么不足？ 如果调味品价格变化怎么办？ 如果增加新的调料怎么办？ 如果一个顾客点了双份的某种调料怎么办？ 面向对象设计的开-闭原则 类应该对扩展开放，对修改封闭。 目的是在不需修改已有代码的情况下方便的扩展类的功能。按照这一原则设计的系统具有以下优点： 具有一定的适应性和灵活性。 具有一定的稳定性和延续性。 装饰模式实战 我们已经看到用继承机制解决我们的咖啡店问题不太理想：或者会导致“类爆炸”，或者是导致基类包含一些子类中并不需要的成分。我们可以换一种做法：从一种基本饮料开始，在运行时用各种调味品对该饮料进行“装饰”。例如，如果一个顾客点了Darkroast咖啡加mocha和whip，那么就可以： 生成一个Darkroast对象 用一个mocha对象装饰它 用一个whip对象装饰它 调用装饰后的对象的cost()方法，依靠委派来计算含调味品的咖啡价钱 何谓装饰？如何装饰？ 所谓装饰就是将一个对象包装起来。 在程序上也就是让一个对象a包含另一个对象b。 a对应的类A是“装饰类”，b对应的类B是被装饰类。 如果要让装饰可以重复，且不必考虑次序，那么装饰的要点是装饰者和被装饰者具有相同的类型（有共同的父类）。 首先我们生成一个DarkRoast对象 然后 再然后 现在，要计算饮料的价格 何谓委派？ 所谓委派就是一个对象将工作（或工作的一部分）交给另一个对象来完成。 在装饰模式中，委派是指装饰对象将任务交给被装饰对象来完成。 委派可以传递，最终必须要有一个干实事的对象。 问题 如果一个顾客点了一份DarkRoast加两份mocha和一份soy，其装饰对象图和价格计算过程有什么样的呢？ 要点 装饰者与被装饰者具有相同的类型 可以用多个装饰者装饰一个对象 由于装饰者与被装饰者具有相同的类型，我们可以用装饰后的对象代替原来的对象。 装饰者在委派它装饰的对象作某种处理时，可以添加上自己的行为（功能扩展）（在委派之前或/和之后）。 对象可以在任何时候被装饰，因此我们能在运行时动态的装饰对象。 装饰模式的定义 装饰模式可以动态的给一个对象附加一些功能。 使用装饰模式扩展功能不会产生类爆炸。它采用的是合成方式，比继承方式更加灵活。 装饰模式的类图结构 咖啡店的类图 咖啡店源代码Beverage.java public abstract class Beverage { String description = Unknown Beverage; public String getDescription() { return description; } public abstract d