设计模式 - 装饰者模式

最新推荐文章于 2025-12-31 22:00:00 发布

原创最新推荐文章于 2025-12-31 22:00:00 发布 · 211 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#设计模式

设计模式专栏收录该内容

25 篇文章

订阅专栏

文章介绍了装饰者模式的概念，它用于动态扩展对象功能，作为继承的替代方案。文中通过一个饮料与配料的例子，展示了如何使用装饰者模式来计算不同配料添加后饮料的成本。每种配料（如牛奶和抹茶）都是装饰者，包装并扩展了基础饮料类的功能，同时保持代码的可扩展性，遵循‘对扩展开放，对修改关闭’的设计原则。

一. 前言

二. 实现

一. 前言

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

装饰者（Decorator）和具体组件（ConcreteComponent）都继承自组件（Component），具体组件的方法实现不需要依赖于其它对象，而装饰者组合了一个组件，这样它可以装饰其它装饰者或者具体组件。所谓装饰，就是把这个装饰者套在被装饰者之上，从而动态扩展被装饰者的功能。装饰者的方法有一部分是自己的，这属于它的功能，然后调用被装饰者的方法实现，从而也保留了被装饰者的功能。可以看到，具体组件应当是装饰层次的最低层，因为只有具体组件的方法实现不需要依赖于其它对象。

二. 实现

设计不同种类的饮料，饮料可以添加配料，比如可以添加牛奶，并且支持动态添加新配料。每增加一种配料，该饮料的价格就会增加，要求计算一种饮料的价格。

下图表示在 DarkRoast（一种咖啡）饮料上新增新添加 Mocha 配料，之后又添加了 Whip（奶油）配料。DarkRoast 被 Mocha 包裹，Mocha 又被 Whip 包裹。它们都继承自相同父类，都有 cost() 方法，外层类的 cost() 方法调用了内层类的 cost() 方法。

/**
 * 饮料
 */
public interface Beverage {
    double cost();
}

/**
 * DarkRoast咖啡
 */
public class DarkRoast implements Beverage {
    @Override
    public double cost() {
        return 1;
    }
}

/**
 * HouseBlend咖啡
 */
public class HouseBlend implements Beverage {
    @Override
    public double cost() {
        return 1;
    }
}

/**
 * 配料装饰者
 */
public abstract class CondimentDecorator implements Beverage {
    protected Beverage beverage;
}

/**
 * 牛奶
 */
public class Milk extends CondimentDecorator {
    public Milk(Beverage beverage) {
        this.beverage = beverage;
    }

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

/**
 * 抹茶
 */
public class Mocha extends CondimentDecorator {
    public Mocha(Beverage beverage) {
        this.beverage = beverage;
    }

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

public class Client {
    public static void main(String[] args) {
        Beverage beverage = new HouseBlend();
        beverage = new Mocha(beverage);
        beverage = new Milk(beverage);
        System.out.println(beverage.cost());
    }
}

设计原则
类应该对扩展开放，对修改关闭：也就是添加新功能时不需要修改代码。饮料可以动态添加新的配料，而不需要去修改饮料的代码。不可能把所有的类设计成都满足这一原则，应当把该原则应用于最有可能发生改变的地方。