TheDecoratorPattern装饰模式.pptVIP

The Decorator Pattern（装饰模式） 问题… 有这么一家咖啡连锁店，可以这样来形容其发展速度:如果今天在你吃午餐的小店边上有一家，明天在它的对面就会看到另一家。 由于生意如此之好，他们便急于升级它的点单系统以满足需要 开始时他们设计的类图如下： 初始类图 问题… 除了咖啡，客人还可以选择一些调味品。每种调味品都要收取一些费用，所以这些也应该包含在点单系统之内。他们想通过每个类的cost()方法来实现。 结果是。。。 类爆炸！！ 这显然是一个恶梦 试设想： 如果咖啡的价格发生变化 如果新出了一种调味品 对系统开发人员来说意味着什么？ 怎么办？ 一种想法是，用实例变量和继承机制来解决各种调味品的问题 新设计方案中基类的类图 新设计方案的类图 基类的cost()代码应该是怎样的？ Public class Beverage { ... public double cost() { } ... } 子类的cost()代码应该是怎样的？ Public class DarkRoast extends Beverage { public DarkRoast() { description=“优质DarkRoast咖啡”; } public double cost() { } ... } 这一设计方案只有五个类 该方案有什么不足？ 如果调味品价格变化怎么办？ 如果增加新的调料怎么办？ 如果一个顾客点了双份的某种调料怎么办？ 面向对象设计的开-闭原则 类应该对扩展开放，对修改封闭。 目的是在不需修改已有代码的情况下方便的扩展类的功能。按照这一原则设计的系统具有以下优点： 具有一定的适应性和灵活性。 具有一定的稳定性和延续性。 讨论 “对扩展开放，对修改封闭。”这听起来自相矛盾啊，怎么可能？ 能否使设计的每一个部分都满足这一设计原则？ 我怎么知道那一部分应该遵循这一设计原则？ 尽管看上去有些自相矛盾，但在设计中实现这一原则是可能的。观察者模式就遵循了这一原则。本讲的装饰模式也遵循这一原则。前面提出的咖啡店问题就可以用装饰模式很好的来解决。 在设计时应该认真选择需要扩展的部分。对设计的每一个部分都应用这一原则是不必要的，不仅费力，而且可能导致复杂难懂的代码。 装饰模式实战 我们已经看到用继承机制解决我们的咖啡店问题不太理想：或者会导致“类爆炸”，或者是导致基类包含一些子类中并不需要的成分。我们可以换一种做法：从一种基本饮料开始，在运行时用各种调味品对该饮料进行“装饰”。例如，如果一个顾客点了Darkroast咖啡加摩卡和蛋奶，那么就可以： 生成一个Darkroast咖啡对象 用一个摩卡对象装饰它 用一个蛋奶对象装饰它 调用装饰后的对象的cost()方法，依靠委派来计算含调味品的咖啡价钱 如何装饰？怎样委派？ 我们将装饰对象想象成一个包装。 首先我们生成一个DarkRoast对象 然后 再然后 现在，要计算饮料的价格 问题 如果一个顾客点了一份DarkRoast加两份mocha和一份soy，其装饰对象图和价格计算过程有什么样的呢？ 要点 装饰者与被装饰者具有相同的类型 可以用多个装饰者装饰一个对象 由于装饰者与被装饰者具有相同的类型，我们可以用装饰后的对象代替原来的对象。 装饰者在委派他装饰的对象作某种处理时，可以添加上自己的行为（功能扩展）（在委派之前或/和之后）。 对象可以在任何时候被装饰，因此我们能在运行时动态的装饰对象。 装饰模式的定义 装饰模式可以动态的给一个对象附加一些功能，对于扩展功能来说，装饰模式（合成）比生成子类的方式（继承）更加灵活。 装饰模式的类图结构 咖啡店的类图 咖啡店源代码Beverage.java public abstract class Beverage { String description = Unknown Beverage; public String getDescription() { return description; } public abstract double cost(); } CondimentDecorator.java public abstract class CondimentDecorator extends Beverage { public abstract String getDescription(); } DarkRoast.java public class DarkRoast extends Beverage { public DarkRoast() { description = Dar