装饰者模式、设计模式

装饰者模式:动态的将责任附加到对象上。想要扩展功能,装饰者提供有别于继承的另一种选择。

  举个例子:星巴兹咖啡(不是星巴克)

  星巴兹扩张速度太快了,他们准备更新订单系统,以合乎他们的饮料供应要求。他们的要求是这样子的:购买咖啡时,可以要求在其中加入各种调料,例如:蒸奶(Steamed Milk)、豆浆(Soy)、摩卡(Mocha,也就是巧克力风味)或者覆盖奶泡。星巴兹会根据所加入的调料不同收取不同的费用。所以订单系统必须考虑到这些调料的部分。

  先来进行第一次尝试:

  设计模式之装饰者模式_设计模式

  哇塞!这简直是“类爆炸”!很明显,按照上面做出来的的系统同样创造了一个维护噩梦。如果调料Milk价格上涨,怎么办?新增加一种调料时,就会诞生多少种新的咖啡?造成这样维护上的困难,违背了我们的设计原则:多用组合,少用继承;要针对接口编程,而不是针对实现编程。

  那我们就换一种方式,先从Beverage基类入手,加上实例变量代表是否加上调料(牛奶、豆浆、摩卡、奶泡、辣椒......)

  设计模式之装饰者模式_装饰者模式_02

  现在加入子类,每个类代表一种饮料。

 设计模式之装饰者模式_子类_03

  认真想一下上面的方法还是有一些潜在的问题。当哪些需求或因素改变时会影响这个设计?

  1.当调料价格的改变会使我们更改现有代码。

  2.一旦出现新的调料,我们就需要加上新的方法,并改变超类中的cost()方法。

  3.以后可能会开发出新饮料。对这些饮料而言(例如:冰茶、绿豆沙冰),某些调料可能并不适合,但是在这个设计方式中,Tea子类仍将继承那些不适合的方法,例如:hasWhip() (加奶泡)。

  4.万一顾客想要双倍牛奶咖啡,怎么办?

  在此我们将介绍最重要的设计原则之一

  类应该对扩展开放,对修改关闭(开放封闭原则)

  现在我们介绍今天的主角:装扮者模式

   以装饰者构造饮料订单

  1.以DarkRoast对象开始

  设计模式之装饰者模式_子类_04

  2.顾客想要摩卡(Mocha),所以建立一个Mocha对象,并用它将DarkRoast对象包装(wrap)起来。

  设计模式之装饰者模式_封装_05

  3.顾客也想要奶泡(Whip),所以需要建立一个Whip装饰者,并用它将Mocha对象包装起来。别忘了,DarkRoast继承自Beverage,且有一个cost()方法,用来计算饮料价格。

  设计模式之装饰者模式_设计模式_06

  4.顾客其实对奶泡情有独钟,所以点了双倍的奶泡.

  设计模式之装饰者模式_子类_07

  5.现在该结账了

  设计模式之装饰者模式_封装_08

  好了,这是目前我们了解的装饰者模式:

  1.装饰者和被装饰者对象有相同的超类型。

  2.你可以用一个或者多个装饰者包装一个对象。

  3.在任何需要原始对象(被包装的)的场合,可以用装饰过的对象代替它。

  4.装饰者可以在所委托被装饰者的行为之前或之后,加上自己的行为,以达到特定的目的。  

  5.对象可以在任何时候被装饰,所以在运行时动态地、不限量地使用你喜欢的装饰者来装饰对象,

  定义装饰者模式:

  动态的将责任附加到对象上。想要扩展功能,装饰者提供比继承更有弹性的替代方案。

  我们来看一下类图:

  设计模式之装饰者模式_装饰者模式_09

  星巴兹咖啡的类图:

  设计模式之装饰者模式_子类_10

 

  现在写下星巴兹的代码:

  先从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

  设计模式之装饰者模式_装饰者模式_11

  

   装饰Java I/O类

  设计模式之装饰者模式_设计模式_12

  但是Java I/O引用装饰者模式引发的一个“缺点”:利用装饰者模式,常常造成设计中有大量的小类,数量实在是太多,可能会造成使用此API程序员的困扰。

  回首看一下我们设计箱内的工具:

  OO基础: 抽象、封装、多态、继承

  OO原则: 封装变化;多用组合,少用继承;针对接口编程,不针对实现编程;为交互对象之间松耦合设计而努力;对扩展开放,对修改关闭;

  OO模式:

  1.策略模式(定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化)

  2.观察者模式(在对象之间定义一对多的依赖,这样一来,当一个对象改变状态,依赖它的对象都会收到通知,并自动更新)

  3.装饰者模式(动态的将责任附加到对象上。想要扩展功能,装饰者提供有别于继承的另一种选择。)

作者: 伊甸一点

本文版权归作者伊甸一点和博客园所有,欢迎转载和商用(须保留此段声明),且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利.