早上八点五十多Yi经有八九个在排队等待了包子铺的热气腾腾地往上冒，把玻璃窗熏得白茫茫一片。我买了两个菜包一共3块，在一旁等着，kan着队伍里那些睡眼惺忪的上班族，心里不禁琢磨起代码世界里的那些事儿。就像这包子，皮是皮，馅是馅，但Ru果你非要给它加个蛋，再淋点辣酱，它就变成了另一种风味。编程里也有这种“加料”的艺术，这就是我们今天要聊的——装饰器模式。

在软件开发的漫长历史中，有些设计模式就像陈年老酒，越品越有味道。装饰器模式就是其中之一。它不像工厂模式那样随处可见，也不像单例模式那样充满争议，但它解决了一个非常棘手的问题：如何在不改变原有对象结构的基础上，动态地给对象添加一些额外的职责？这听起来有点像变魔术，不是吗？

穿衣打扮的艺术：理解装饰器的核心

为了搞懂这个概念，我们不妨先从生活琐事入手。想象一下Pkmer 今天要出门见客户，需要给自己好好打扮一番。商店里的选择多得让人眼花缭乱：有休闲的球鞋、松垮的垮裤、宽松的大T恤，也有正式的皮鞋、笔挺的领带、昂贵的西装等。

Ru果按照传统的继承思维，我们可Neng需要为每一种组合dou创建一个类：“穿球鞋垮裤T恤的Pkmer”、“穿西装领带皮鞋的Pkmer”……这简直是灾难，类的数量会呈爆炸式增长。但聪明的程序员不会这么干。Pkmer 不需要从零开始穿衣，而是在现有装扮的基础上，一件件套上新的衣服。每件衣服douNeng“展示”自己，同时把展示的机会留给里面Yi经穿好的衣服。

这种层层包裹的逻辑，正是装饰器模式的精髓。我们先穿内层，再穿外层，但展示的时候，往往是从Zui外层开始描述。比如：

---------第一种装扮---------------
球鞋垮裤大T桖装扮的Pkmer
---------第二种装扮---------------
西装领带皮鞋装扮的Pkmer

模式结构剖析

让我们把这个穿衣的过程抽象成代码结构。这就像是一个俄罗斯套娃，每一层dou包含着下一层。

┌─────────────────┐
│   ICharacter    │  ← 接口，定义 show 方法
└────────┬────────┘
         │
    ┌────┴────┐
    │         │
┌───▼───┐ ┌───▼────────┐
│ Person│ │  Finery    │  ← 装饰器基类
└───────┘ └───┬────────┘
              │
    ┌─────────┼─────────┬─────────┐
    │         │         │         │
┌───▼───┐ ┌───▼──┐ ┌───▼───┐ ┌───▼────┐
│Sneakers│ │BigTrouser│TShirts│ │Suit... │  ← 具体装饰类
└───────┘ └──────┘ └───────┘ └────────┘

核心思想拆解

组件接口这是Zui基础的契约，定义了大家dou必须遵守的行为，比如 show 方法。

具体组件这是被装饰的对象，也就是那个光着身子等待穿衣的“Pkmer”。

装饰器基类它实现了接口，但并不干实事，而是持有一个组件引用，负责把请求传递给被装饰者。

具体装饰类这些是真正的“衣服”。在展示时它们先输出自己的特征，再调用 super.show 把球踢给下一层。

这样一来装扮顺序在代码逻辑上是从外到内递归调用，但实际穿衣过程是从内到外层层包裹的。是不是hen有意思？

Java代码实现：穿衣模拟

我们定义那个Zui基本的接口：

public interface ICharacter {
    void show;
}

然后是我们的主角，那个还没穿衣服的 Person：

public class Person implements ICharacter {
    private String name;
    public Person {
        this.name = name;
    }
    @Override
    public void show {
        System.out.println;
    }
}

接下来是装饰器的基类，它就像一个衣架，用来挂住具体的衣服或者里面的人：

public class Finery implements ICharacter {
    private ICharacter component;
    public void decorator {
        this.component = component;
    }
    @Override
    public void show {
        if  {
            component.show;
        }
    }
}

终于到了具体的衣服了比如这件大T恤：

public class TShirts extends Finery {
    @Override
    public void show {
        System.out.print;
        super.show;  // 先输出自己，再调用内部组件
    }
}

Zui后kankan客户端怎么把这些衣服穿起来：

public class Main {
    public static void main {
        Person pkmer = new Person;
        TShirts tShirts = new TShirts;
        BigTrouser bigTrouser = new BigTrouser;
        Sneakers sneakers = new Sneakers;
        // 从内到外层层包装
        tShirts.decorator;
        bigTrouser.decorator;
        sneakers.decorator;
        // 输出时从外到内
        sneakers.show;  // 输出：球鞋垮裤大T桖装扮的Pkmer
    }
}

你kan，当需要 其他装扮的时候，我们只需要新建一个装饰类，实现 show 方法，调用 super.show 即可，完全不需要修改现有的代码。这就是开闭原则的完美体现。

商场收银系统：复杂的业务逻辑组合

Ru果说穿衣还只是简单的装饰，那么商场收银系统就是装饰器模式大显身手的战场了。我们需要支持多种收费方式：正常收费、打折、满减，以及它们的疯狂组合。

用户Ke以选择不同的收费模式，系统必须像精明的会计一样，自动计算Zui终的收费金额。比如：

***商品折扣模式如下:***
.正常收费
.打八折
.打七折
.满300送100
.先打8折，再满300送100
.先满200送50，再打7折
请输入商品折扣模式:
请输入商品单价：
请输入商品数量：
单价：.0元 数量： 合计：.0元
总计：.0元

模式结构设计

这里我们依然沿用装饰器的经典结构，但内容变成了金钱的计算：

┌─────────────────┐
│     ISale       │  ← 组件接口
└────────┬────────┘
         │
    ┌────┴────┐
    │         │
┌───▼───┐ ┌───▼────────┐
│CashNormal│ │ CashSuper │  ← 装饰器基类
└───────┘ └───┬────────┘
              │
    ┌─────────┼─────────┐
    │         │         │
┌───▼───┐ ┌───▼──┐ ┌───▼───┐
│CashRebate│ │CashReturn│ │...    │  ← 具体装饰类
└───────┘ └──────┘ └───────┘

核心思想解析

组件接口定义了Zui核心的收费行为 acceptCash。

具体组件这是Zui朴实的收费方式，原价出售，一分不少。

装饰器基类它持有对下一个计算策略的引用，负责传递计算结果。

具体装饰类这些是具体的算法。打折装饰类先算折扣，然后把结果传给下一个；返利装饰类先算满减，再往下传。

代码实现细节

是接口，简单明了：

public interface ISale {
    double acceptCash;
}

正常收费，也就是原价计算：

public class CashNormal implements ISale {
    @Override
    public double acceptCash {
        return price * num;  // 原价收费
    }
}

装饰器基类，这里的关键在于它如何持有引用：

public class CashSuper implements ISale {
    private ISale component;
    public void decorate {
        this.component = component;
    }
    @Override
    public double acceptCash {
        double result = 0;
        if  {
            result = component.acceptCash;  // 调用内部组件计算
        }
        return result;
    }
}

打折逻辑，这里要注意参数的校验，毕竟折扣不Neng是负数：

public class CashRebate extends CashSuper {
    private double rebate;
    public CashRebate {  // 比如 0.8 表示打8折
        if  {
            throw new IllegalArgumentException;
        }
        this.rebate = rebate;
    }
    @Override
    public double acceptCash {
        double result = price * num * rebate;  // 先计算打折后的价格
        return super.acceptCash;  // 传递给内部组件，数量变为1，因为金额Yi经算好
    }
}

返利逻辑，也就是满减：

public class CashReturn extends CashSuper {
    private double moneyCondition = 300.0d;  // 返利条件，如满300
    private double moneyReturn = 100.0d;    // 返利金额，如返100
    public CashReturn {
        this.moneyCondition = moneyCondition;
        this.moneyReturn = moneyReturn;
    }
    @Override
    public double acceptCash {
        double result = price * num;
        if  {
            result = result - Math.floor * moneyReturn;
        }
        return super.acceptCash;
    }
}

Zui精彩的部分在于上下文类，它负责根据用户的输入，像搭积木一样组合这些装饰器：

public class CashContext {
    private final ISale cs;
    public CashContext {
        cs = switch  {
            case 1 -> new CashNormal;  // 正常收费
            case 2 -> new CashRebate;  // 打8折
            case 3 -> new CashRebate;  // 打7折
            case 4 -> new CashReturn;  // 满300返100
            case 5 -> {  // 先打8折,再满300返100
                CashNormal cn = new CashNormal;
                CashReturn cashReturn = new CashReturn;
                CashRebate cashRebate = new CashRebate;
                cashReturn.decorate;
                cashRebate.decorate;
                yield cashRebate;
            }
            case 6 -> {  // 先满200返50，再打7折
                CashNormal cashNormal = new CashNormal;
                CashRebate cashRebate = new CashRebate;
                CashReturn cashReturn = new CashReturn;
                cashRebate.decorate;
                cashReturn.decorate;
                yield cashReturn;
            }
            default -> throw new IllegalArgumentException;
        };
    }
    public double getResult {
        return cs.acceptCash;
    }
}

客户端调用起来就非常简洁了：

public class Main {
    public static void main {
        try ) {
            double total = 0d;
            while  {
                // ... 输入逻辑
                CashContext cashContext = new CashContext;
                totalPrices = cashContext.getResult;
                total += totalPrices;
            }
        }
    }
}

小结：组合的力量

利用基础 CashNormalCashRebateCashReturn 这三种原子算法，通过装饰器模式，我们Ke以有选择地、有顺序地组合它们，形成千变万化的策略。这比写一堆 CashRebateAndReturnCashReturnAndRebate 的子类要优雅得多，也灵活得多。

为何要选择装饰器模式？

装饰器模式不仅仅是一种代码技巧，geng是一种设计哲学。它告诉我们：把每个要装饰的功Neng，放在单独的类中，并让这些新类包装它所要装饰的对象。客户端使用时Ke以根据需要，有选择地、有顺序地使用装饰功Neng包装对象了。

在实际开发中，找到那个基础类 ConcreteComponent是关键。一旦你找到了它，剩下的就是像玩乐高一样，构建你的装饰器类库。无论是处理Java IO流中的 BufferedReader，还是在Spring框架中处理Bean的生命周期，装饰器模式dou在默默地发挥着它的光和热。

所以下次当你面对一堆复杂的 if-else 或者是为了 功Neng而不得不修改原有代码时不妨停下来想一想：是不是该用这件“古法”外衣，给我的代码对象穿上一件新衣服了？

---