【设计模式】装饰器模式（Decorator Pattern）

 

🔥 核心

装饰器模式是对现有类的一个包装，是继承的一种替代方案。

装饰类中拥有一个指向现有类的成员变量。

 

🙁 问题场景

你是一名MOBA游戏设计师。

在你设计的这个MOBA游戏中，英雄升级后可以选择学习一个附加的技能。现在，有一名 英雄(Hero) ，他的名字叫 捕鲨者(SharkKiller) ，随着等级的提升他可以学习的技能有 Q 、W 、E 、R 。

这时作为设计师的你犯了难——根据开闭原则，你不想改变原生 捕鲨者 的代码，所以当他学习了技能后，你需要派生出多个子类 学习了Q的捕鲨者(SharkKillerWithQ) 、学习了W的捕鲨者(SharkKillerWithW) 、学习了E的捕鲨者(SharkKillerWithE) 、学习了R的捕鲨者(SharkKillerWithR) 。

可是，这样的设计似乎不是那么优雅。

 

🙂 解决方案

装饰器模式正是继承的一种替代方案。你想到了一个好主意。

你从一个较高的抽象层次做出了一个抽象的装饰类 学习类某个技能的英雄(HeroWithSkill) ，在这个类中，拥有一个指向 英雄(Hero) 的成员变量；这个抽象的装饰类有四个具体的实现 学习了Q的英雄(HeroWithQ) 、学习了W的英雄(HeroWithW) 、学习了E的英雄(HeroWithE) 、学习了R的英雄(HeroWithR)，它们是对现有类的具体装饰和具体增强。

如何使用这几个装饰类呢？向装饰类传入一个 捕鲨者 对象，赋值给成员变量，捕鲨者 就可以作为成员变量在装饰器中得到装饰和增强了！当然，传入装饰器的不一定是 捕鲨者 ，可以是任何一种 英雄 。

相比于继承，这种即插即用的设计是不是也很优雅呢？

 

🌈 有趣的例子

这里有一只原生 萝莉 。你想给她穿上不同的衣服，来装饰一下。

 萝莉(接口)
interface Loli {
    void introduce();
}

 爱丽丝(萝莉的普通实现类)
class Alice implements Loli {
    private String name = "Alice";

    @Override
    public void introduce() {
        System.out.println("我的名字是" + name + "～");
    }
}


 修饰器(给萝莉穿上不同的衣服)
abstract class LoliClothing implements Loli {
    // 一个指向萝莉对象的成员变量(关键)
    // 这个成员变量等待着被传入的参数赋值
    private Loli loli;

    public LoliClothing(Loli loli) {
        this.loli = loli;
    }

    @Override
    public void introduce() {
        loli.introduce();
    }
}

 换装———哥特萝莉
class GothClothing extends LoliClothing {

    public GothClothing(Loli loli) {
        super(loli);
    }

    // 萝莉对象的方法得到增强
    @Override
    public void introduce() {
        super.introduce();
        dress();
    }

    private void dress() {
        System.out.println("我是一只哥特萝莉>_<");
    }
}

 换装———猫耳萝莉
class NekoClothing extends LoliClothing {

    public NekoClothing(Loli loli) {
        super(loli);
    }

    // 萝莉对象的方法得到增强
    @Override
    public void introduce() {
        super.introduce();
        dress();
    }

    private void dress() {
        System.out.println("我是一只猫耳萝莉>_<");
    }
}

 换装———泳装萝莉
class SwimClothing extends LoliClothing {

    public SwimClothing(Loli loli) {
        super(loli);
    }

    // 萝莉对象的方法得到增强
    @Override
    public void introduce() {
        super.introduce();
        dress();
    }

    private void dress() {
        System.out.println("我是一只泳装萝莉>_<");
    }
}

public class DecoratorPatternDemo {
    public static void main(String[] args) {

        // 捕获一只原生萝莉
        Loli alice = new Alice();

        // 换装———哥特萝莉
        GothClothing gothClothingLoli = new GothClothing(alice);
        gothClothingLoli.introduce();

        // 换装———猫耳萝莉
        NekoClothing nekoClothingLoli = new NekoClothing(alice);
        nekoClothingLoli.introduce();

        // 换装———泳装萝莉
        SwimClothing swimClothingLoli = new SwimClothing(alice);
        swimClothingLoli.introduce();
    }
}

我的名字是Alice～
我是一只哥特萝莉>_<

我的名字是Alice～
我是一只猫耳萝莉>_<

我的名字是Alice～
我是一只泳装萝莉>_<

 

☘️ 使用场景

◾️如果你希望在无需修改代码的情况下即可使用对象，且希望在运行时为对象新增额外的行为，可以使用装饰模式。

装饰能将业务逻辑组织为层次结构，你可为各层创建一个装饰，在运行时将各种不同逻辑组合成对象。由于这些对象都遵循通用接口，客户端代码能以相同的方式使用这些对象。

◾️如果用继承来扩展对象行为的方案难以实现或者根本不可行，你可以使用该模式。

许多编程语言使用 final 最终关键字来限制对某个类的进一步扩展。复用最终类已有行为的唯一方法是使用装饰模式：用封装器对其进行封装。

 

🧊 实现方式

（1）确保业务逻辑可用一个基本组件及多个额外可选层次表示。

（2）找出基本组件和可选层次的通用方法。创建一个组件接口并在其中声明这些方法。

（3）创建一个具体组件类，并定义其基础行为。

（4）创建装饰基类，使用一个成员变量存储指向被封装对象的引用。该成员变量必须被声明为组件接口类型， 从而能在运行时连接具体组件和装饰。装饰基类必须将所有工作委派给被封装的对象。

（5）确保所有类实现组件接口。

（6）将装饰基类扩展为具体装饰。具体装饰必须在调用父类方法（总是委派给被封装对象）之前或之后执行自身的行为。

（7）客户端代码负责创建装饰并将其组合成客户端所需的形式。

 

🎲 优缺点

  ➕ 你无需创建新子类即可扩展对象的行为。

  ➕ 你可以在运行时添加或删除对象的功能。

  ➕ 你可以用多个装饰封装对象来组合几种行为。

  ➕ 单一职责原则。你可以将实现了许多不同行为的一个大类拆分为多个较小的类。

  ➖ 在封装器栈中删除特定封装器比较困难。

  ➖ 实现行为不受装饰栈顺序影响的装饰比较困难。

  ➖ 各层的初始化配置代码看上去可能会很糟糕。

 

🌸 补充

 装饰器即插即用，非常好用！

 

🔗 参考网站

• Cbc.net
• Runoob.com
• Refactoring.Guru