游戏设计模式阅读笔记11——行为模式（子类沙箱）

目录

一、意图

二、动机

三、子类沙箱

1.适用场景：

2.缺点：

3. 优化：

4.可不写入基类的操作

---

       

子类沙箱是一种软模式，它表述了一个基本思路，但没有很多细节机制。

一、意图

         用一系列由基类提供的操作定义子类中的行为。

二、动机

         当我们创建一个Superpower基类，然后由他派生很多的超能力种类。如果由每个子类自己控制物理，音效，UI。就会造成很多冗余代码，与引擎高度耦合，不易维护，很难管理。

        解决方法就是将这些会被高度复用的代码写成Superpower基类的protected函数，可以是虚函数，也可以不是。子类只能调用它。

        而沙箱方法，就是子类必须实现的抽象的protected方法。

        这样就将耦合约束到了一个地方。当外部改变时，我们可以只改变基类，但众多子类不需要修改。

三、子类沙箱

        基类定义抽象的沙箱方法和几个提供的操作。将操作标为protected，表明它们只为子类所使用。每个推导出的沙箱子类用提供的操作实现了沙箱函数。

1.适用场景：

        1.基类需要推导很多的子类

        2.基类可以提供子类需要的所有操作

        3.在子类中有行为重复，需要复用代码

        4.想要最小化子类和程序的其他部分耦合

2.缺点：

        基类的代码会越来越多，并紧密的与子类绑定，能难在不改变破坏子类的情况下改变基类——脆弱的基类。

3. 优化：

        考虑将基类的一些操作放入分离的类中，组件模式可以帮上忙。这样就减少了基类中的方法，减少了基类与其他系统的耦合，在辅助类中的代码更好的管理。

        比如实现这个声音的类。

4.可不写入基类的操作

        1.少数类收益，建议子类直接调用外部系统。

        2.如果子类调用了其他地方的方法，但是没有修改状态，就是安全的耦合。

        3.如果操作只是增加了外部系统的转发调用，就可以只截调用。