策略模式实战：从硬编码到算法解耦的演进之路

代码看起来行云流水，复用性似乎也不错。提交代码后，一切都很完美。

1.2 危机降临：新物种的挑战

随着业务扩展，甲方提出了新需求：系统要支持北极熊、熊猫，甚至玩具熊。

这时候问题暴露了。为了偷懒，我把 Hibernation（冬眠）和 ClimbTree（爬树）直接写死在基类里了。

• 北极熊：生活在极地，根本不需要冬眠。
• 玩具熊：连生命都没有，更谈不上爬树。

如果继续用继承，我只能在每个子类里重写这些方法，覆盖掉基类的默认实现。

class PolarBear : public Bear {
public:
    // 必须重写，因为北极熊不冬眠
    void Hibernation() { std::cout << "不需要冬眠" << std::endl; }
    // ... 其他逻辑
};

如果有 100 种不冬眠的熊，我就得写 100 遍'不冬眠'的逻辑。继承在这里不仅没有带来复用，反而造成了耦合。一旦某个行为的逻辑发生变化，我可能需要修改多个子类，或者基类的改动会影响所有子类。

二、重构思路：组合优于继承

痛定思痛，我们需要重新审视设计原则：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。

简单说就是：既然'怎么爬树'和'怎么冬眠'是会变的，那就把它们踢出 Bear 类，单独封装！

我们要把'行为'变成一种'零件'，哪只熊需要什么零件，组装上去就行了。这就是组合。我们将基类的方式实现进行封装，对代码进行重构。

现在，Bear 类不再亲自负责实现'爬树'这个动作，它只负责拥有一个'爬树行为'的接口。具体怎么爬？让接口的实现类去操心吧！

三、最终方案：策略模式落地

为了代码整洁，我们专注于重构 Hibernation 和 ClimbTree 这两个变化点。

3.1 抽象行为接口

先把'怎么冬眠'抽象成一个接口族：

class Hibernation_Behavior {
public:
    virtual void Hibernation() = 0;
};

class Hibernation_able : public Hibernation_Behavior {
public:
    void Hibernation() override {
        std::cout << "进行冬眠" << std::endl;
    }
};

class Hibernation_unable : public Hibernation_Behavior {
public:
    void Hibernation() override {
        std::cout << "不需要冬眠" << std::endl;
    }
};

3.2 拆分其他行为

同理，把爬树能力也拆分出来：

class ClimbTree_Behavior {
public:
    virtual void ClimbTree() = 0;
};

class ClimbTree_able : public ClimbTree_Behavior {
public:
    void ClimbTree() override {
        std::cout << "会爬树" << std::endl;
    }
};

class ClimbTree_unable : public ClimbTree_Behavior {
public:
    void ClimbTree() override {
        std::cout << "不需要爬树" << std::endl;
    }
};

3.3 重构 Bear 类

现在的 Bear 类不再包含具体实现，而是持有行为对象的指针。这里使用 std::shared_ptr 来管理生命周期。

class Bear {
public:
    virtual void Hibernation() = 0;
    virtual void ClimbTree() = 0;
protected:
    std::shared_ptr<Hibernation_Behavior> hibernation_behavior_;
    std::shared_ptr<ClimbTree_Behavior> climbTree_behavior_;
};

3.4 实例化与装配

各种熊的实现变得非常清晰，只需要在构造函数中装配对应的行为即可。

class BrownBear : public Bear {
public:
    BrownBear() {
        hibernation_behavior_ = std::make_shared<Hibernation_unable>();
        climbTree_behavior_ = std::make_shared<ClimbTree_able>();
    }
    void Hibernation() {
        hibernation_behavior_->Hibernation();
    }
    void ClimbTree() {
        climbTree_behavior_->ClimbTree();
    }
};

class Panda : public Bear {
public:
    Panda() {
        hibernation_behavior_ = std::make_shared<Hibernation_unable>();
        climbTree_behavior_ = std::make_shared<ClimbTree_able>();
    }
    void Hibernation() {
        hibernation_behavior_->Hibernation();
    }
    void ClimbTree() {
        climbTree_behavior_->ClimbTree();
    }
};

四、总结

这就是传说中的策略模式（Strategy Pattern）！

通过把 Hibernation_Behavior 和 ClimbTree_Behavior 定义为算法族，我们将行为的实现与使用行为的 Bear 类彻底解耦。

好处显而易见：

1. 复用性起飞：如果不冬眠的代码逻辑变了，我只需要改 Hibernation_unable 这一个类，所有不冬眠的熊都会自动更新。
2. 扩展性无敌：如果需要加个'机械熊'，我只需要新写一个 RocketJump_Behavior，然后在机械熊里装配上就行，根本不用去动原来的代码。

最后策略模式定义就是：定义算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

这种设计让代码更加灵活，能够应对不断变化的业务需求，是面向对象设计中处理多态场景的经典方案。