其他分享
首页 > 其他分享> > 3 装饰者模式

3 装饰者模式

作者:互联网

1.绪

运行时扩展,远比编译时期的继承威力更大。本章可以成为“给爱用继承的人一个全新的设计眼界”。

本章将再度讨论典型的继承滥用问题。本章中将讲解如何使用对象组合的方式,做到运行时装饰类。一旦熟悉了装饰的技巧,则能够在不修改任何底层代码的情况下,给对象赋予新的职责。

2.应用背景-问题引入

咖啡店的故事:一家快速扩张的咖啡连锁店准备更新订单系统,以合乎他们的饮料供应要求。

原先的类设计

购买咖啡时,可以要求在其中加入各种调料,例如:蒸奶(Steamed Milk)、豆浆(Soy)、摩卡(Mocha,也就是巧克力风味)或者覆盖奶泡。咖啡店会根据加入的调料收取不同的费用,因此订单系统必须考虑到这些调料部分。

这是该咖啡店的第一个尝试:

 很明显,这制造了一个维护噩梦。因为如果某个调料的价格上涨或者需要新增一种调料,则会导致维护困难。

书上的初步尝试:

 现在加入子类,每个类就代表菜单上的一种饮料:

 这样改变带来的影响

当一些需求或者因素改变时将会影响这个设计:

  1. 调料价钱改变会使我们改变现有代码
  2. 一旦出现新的调料,则需要加上新的方法,则改变超类中的cost()方法
  3. 以后可能会开发出新饮料,对这些饮料而言(例如,冰茶),某些调料可能并不适合,但是在这个设计方式中,Tea(茶)子类仍将继承那些不适合的方法,例如,hasWhip()(加奶泡)。
  4. 万一顾客想要双倍摩卡咖啡,则对那么办?

关于组合和委托

虽然继承威力强大,但是继承不总是能够实现最有弹性和最好维护的设计。

利用组合和委托可以在运行时具有继承行为的效果。

利用继承设计子类的行为,是在编译时静态决定的,而且所有的子类都会继承到相同的行为。然而,如果能够利用组合的做法扩展对象的行为,就可以在运行时动态地进行扩展。则可以利用此技巧把多个新职责,甚至是设计超类时还没想到的职责加在对象上,而且不需要修改原来的代码。

利用组合维护代码,能够通过动态地组合对象,写新的代码添加新功能,而无需修改现有代码,既然没有改变现有代码,那么引进Bug或者产生意外副作用的机会将大幅度减少。

3.开放-关闭原则

设计原则:类应该对扩展开放,对修改关闭。

我们的目标是允许类容易扩展,在不修改现有代码的情况下,就可搭配新的行为。实现这一目标的好处:具有弹性可以应对改变,可以接受新的功能来应对改变的需求。

相关问答:

Q1:对扩展开放,对修改关闭,听起来很矛盾,在设计的时候该如何兼顾?

A1:有一些聪明的OO技巧,允许系统在不修改代码的情况下,进行功能扩展。比如观察者模式,通过加入新的观察者,我们可以在任何时间扩展Subject(主题),而且不需要向主体中添加代码。以后,还会看到更多的扩展行为的其他OO设计技巧。

Q2:如何将某件东西设计成可以扩展,又禁止修改?

A2:在本章将使用装饰者模式的一个好例子,完全遵循开放-关闭原则。

Q3:如何设计的每个部分都遵循开放-关闭原则?

A3:通常,是办不到的,要让OO设计同时具备开放性和关闭性,又不修改现有的代码,需要花费许多时间和努力。一般来说,不会把设计的每个部分都这么设计,即便做到了,也可能是一种浪费。遵循开放-关闭原则,通常会引入新的抽象层次,增加代码的复杂度。那么需要将注意力集中在设计中最有可能改变的地方,然后应用开放-关闭原则。

4.认识装饰者模式

通过问题引入已经得知,无法利用继承来完全解决问题,遇到的问题有:类数量爆炸、设计死板,以及基类加入的新功能并不适用于所有的子类。

因此,在这里要采用不一样的做法:要以饮料为主题,然后在运行时以调料来“装饰”(decorate)饮料。比如,如果顾客想要摩卡和奶泡深焙咖啡,那么需要做的是:

  1.  拿一个深焙咖啡(DarkRoast)对象
  2. 以摩卡(Mocha)对象装饰他
  3. 以奶泡(Whip)对象装饰他
  4. 调用cost()方法,并依赖委托(delegate)将调料的价钱加上去

以装饰者构建饮料订单

第一步:以DarkRoast对象开始

 第二步:顾客下你给要摩卡(Mocha),所以建立一个Mocha对象,并用它将DarkRoast对象包(wrap)起来。

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

 第四步:到为顾客算钱的时候了。通过调用最外圈装饰者(Whip)的cost()就可以办得到。Whip的cost()会先委托它装饰的对象(也就是Mocha)计算出价钱,然后再加上奶泡的价钱。

 到此则装饰结束。这就是目前所知道的一切:

  1. 装饰者和被装饰对象有相同的超类型。
  2. 可以用一个或多个装饰者包装一个对象
  3. 既然装饰者和被装饰对象有相同的超类型,所以在任何需要原始对象(被包装的)场合,可以用装饰过的对象代替它。
  4. 装饰者可以在所委托被装饰者的行为之前与/或之后,加上自己的行为,以达到特定的目的。
  5. 对象可以在任何时候被装饰,所以可以在运行时动态地,不限量地用所喜欢的装饰者来装饰对象。

接下来就看看装饰者模式的定义,并写一些代码,了解它到底是怎么工作的。

5.定义装饰者模式

5.1 装饰者模式的说明

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

装饰者模式的类图:

需要知道的是:每个装饰者都包装一个组件,也就是说,装饰者有一个实例变量以保存某个Component的引用。装饰者本身也是继承自Component的。

 

 5.2 装饰饮料

将咖啡店的饮料应用在这个框架上:

 组件其实就是被装饰者

 5.3 关于继承和组合之间,混淆的观念

通过类图可知,CondimentDecorator扩展自Beverage类,这用到了继承。这么做的重点在于:装饰者和被装饰者必须是一样的类型,即拥有共同的超类,这是相当关键的,因为我们利用继承达到“类型匹配”,而不是利用继承获得“行为”。

装饰者需要和被装饰者(被包装的组件)有相同的“接口”,因为装饰者必须能取代被装饰者,但是行为又是从哪里来的?当我们将装饰者和组件组合时,就是在加入新的行为。所得到的新行为,并不是继承自超类,而是由组合对象得来的。继承Beverage抽象类,是为了有正确的类型,而不是继承他的行为。行为来自装饰者和基础组件,或与其他装饰者之间的组合关系。因为使用对象组合,可以把所有饮料和调料更加有弹性的加以混合与匹配,如果只是依赖继承,那么类的行为只能在编译时静态决定,即行为不是来自超类,那么就是子类覆盖后的版本。反之,利用组合,可以把装饰者混合着用,并且是在“运行时”。并且这样的话,就能够在任何时候,实现新的装饰者增加新的行为。如果依赖继承,每当需要新行为时,还得修改现有的代码。

如果需要继承的是component类型,为什么不把Beverage类设计成一个接口,而是设计成一个抽象类呢?通常装饰者模式采用抽象类,但是在JAVA中可以使用接口。尽管如此,通常我们都努力避免修改现有的代码,所以,如果抽象类运作得好好地,还是别去修改它。

6.代码实现

6.1 基类和装饰者类的实现

首先从Beverage类下手,这不需要改变咖啡店原始的设计:

public abstract class Beverage {

    String description="Unkonwn Beverage";

    public String getDescription() {
        return description;
    }

    public abstract double cost();
}

 Beverage很简单。同样来实现调料的抽象类Condiment,,也就是装饰者类:

//首先,必须让CondimentDecorator能够取代Beverage,所以CondimentDecorator扩展自Beverage类
public abstract class CondimentDecorator extends Beverage{

    //所有的调料装饰者都必须重新实现getDescription()方法。
    @Override
    public abstract String getDescription();

}

6.2 写饮料的代码

基类已经建立完成了,则开始实现一些饮料。

首先创建 浓缩咖啡(Espresso)开始,我们需要为具体的饮料设置描述,而且还必须实现cost()方法。

//首先,让Espresso扩展自Beverage类,因为Espresso是一种饮料
public class Espresso extends Beverage{

    //为了要设置饮料的描述,我们写了一个构造器,记住:description实例变量继承自Beverage。
    public Espresso() {
        description="Espresso";
    }

    //最后,需要计算Espresso的价钱,现在不管调料的价钱,直接把Espresso的价格返回即可
    @Override
    public double cost() {
        return 1.99;
    }
}

同样的,编写HouseBlend的相关代码:

public class HouseBlend extends Beverage{

    public HouseBlend() {
        description="HouseBlend";
    }

    @Override
    public double cost() {
        return .89;
    }
}

6.3 写调料代码

上面完成了抽象组件,具体组件,也有了抽象装饰者。现在,就来实现具体装饰者。

首先编写摩卡Mohca类:

//Mocha是一个装饰者,所以让他扩展自 CondimentDecorator
public class Mocha  extends CondimentDecorator{
    //要让Mocha能够引用一个Beverage,做法如下
    //1.用一个实例变量记录饮料,也就是被装饰者
    //2.想办法让被装饰者(饮料)被记录到实例变量中。这里的做法是:
    //把饮料当做构造器的餐宿,再由构造器将其饮料记录在实例变量中
    Beverage beverage;

    public Mocha(Beverage beverage) {
        this.beverage = beverage;
    }

    @Override
    public String getDescription() {
        return beverage.getDescription()+",Mocha";
    }

    //要计算带Mocha饮料的价格。首先把调用委托给被装饰对象,以计算价钱,然后再加上Mocha的价钱,得到最后结果
    @Override
    public double cost() {
        return .20+beverage.cost();
    }
}

同理写下 Soy和Whip调料的代码:

public class Whip extends CondimentDecorator {

    Beverage beverage;

    public Whip(Beverage beverage) {
        this.beverage = beverage;
    }

    @Override
    public String getDescription() {
        return beverage.getDescription()+",Whip";
    }


    @Override
    public double cost() {
        return .10+beverage.cost();
    }
}

public class Soy extends CondimentDecorator {

    Beverage beverage;

    public Soy(Beverage beverage) {
        this.beverage = beverage;
    }

    @Override
    public String getDescription() {
        return beverage.getDescription()+",Soy";
    }


    @Override
    public double cost() {
        return .15+beverage.cost();
    }
}

6.4 供应咖啡

编写测试代码

public class StarbuzzCoffee {

    public static void main(String[] args) {
        Beverage beverage=new Espresso();
        beverage=new Mocha(beverage);
        beverage=new Whip(beverage);
        System.out.println(beverage.getDescription()+" $ "+beverage.cost());
    }
}

实验结果:

 

标签:cost,模式,public,Beverage,Mocha,装饰,beverage
来源: https://blog.csdn.net/qq_35863981/article/details/122805228