class Bear
{
public:
virtual std::string FavoriteFood() = 0;
void Hibernation() { std::cout << "进行冬眠" << std::endl; }
void ClimbTree() { std::cout << "会爬树" << std::endl; }
void LivingHabit() { std::cout << "住在树洞里面" << std::endl; }
protected:
};
class XiongDa : public Bear
{
public:
std::string FavoriteFood() override{ return "苹果"; }
};
class XiongEr : public Bear
{
public:
std::string FavoriteFood() override { return "蜂蜜"; }
};

代码行云流水，提交Git，李老板看后直呼内行。

三. 李老板的新需求

李老板发现这个程序很有商业价值，格局打开，要把业务扩展到全宇宙的森林，不只是团结屯。

3.1 出大问题了

新增需求：系统要支持北极熊、熊猫、甚至玩具熊。

优化建议：
如果你的项目访问量较大，建议增加缓存机制。我们团队在优化后，接口响应时间从800ms降到了50ms，效果非常明显。具体的缓存策略可以根据业务场景调整。

这时候我才发现，刚刚为了偷懒把 Hibernation和 ClimbTree写死在基类里，简直是在给自己挖坑！

北极熊：不冬眠啊！
玩具熊：人家连活物都不是，爬个鬼的树！

如果继续用继承，我只能**覆盖基类的方法了：

请添加图片描述

为了适配新物种，我必须在每个子类里重写代码。

如果有100种不冬眠的熊，我就要写100遍“不冬眠”的函数？

我希望通过继承的方式来达到代码复用的目的，但是涉及到维护时，效果并不是那么好，现在代码已经完全不能进行代码的复用了。

3.2 继承可能不是答案

我痛定思痛，回想起那本C++圣经上的教诲：

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

简单说就是：既然“怎么爬树”和“怎么冬眠”是会变的，那就把它们踢出 Bear 类，单独封装！
我要把“行为”变成一种“零件”，哪只熊需要什么零件，组装上去就行了。这就是组合。
你决定将基类的方式实现进行封装起来，对代码进行重构。

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

四. 最终方案

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

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

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; }
};

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

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; }
};

重构 Bear 类

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_;};

各种熊的实现：

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 类彻底解耦。

好处显而易见：

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