1.策略模式能解决什么问题？

前面学习了很多种设计模式，通过实际的例子来进行学习，好像确实在那个例子里解决了问题，但是我们现实中的需求和例子中的往往不一样，那么我们该如何判断现实项目中策略模式能解决什么问题呢？

这一节就策略模式的实用性迁移展开了一些讨论，纯属个人见解，仅供参考！

1.1 复习一下策略模式

如果看不懂下面的UML图，请跳转到策略模式详细学习博客进行学习后再来(有完整项目代码)：
https://blog.csdn.net/c1776167012/article/details/124650097?spm=1001.2014.3001.5502

策略模式定义了算法族，将具体的算法各自封装起来，让他们之间可以相互替换，并让算法的变化独立于使用算法的客户。

首先，我们结合下面的UML图来解析一下：

在上面的设计中，MallardDuck和RedheadDuck是客户，而FlyBehavior是一个飞行行为算法族，它可以有多种不同的实现（就是具体的算法），这种每种实现都可以组合进客户，因为每种实现都实现了FlyBehavior接口。所以这些具体的实现的变化并不会影响客户。

在这个例子中，策略模式提供了当一个类组合的接口的具体实现类发生了变化时，不用更改此类原有代码，只需新增相应的实现类，然后进行相应的注入配置即可的编程方式。这样使我们的系统扩展性更强且易于扩展。

2.1 现实项目中什么地方能用到策略模式呢？

实际上我们可以理解一下策略模式这个名字，其实就是表示，情况不同，策略不同原则嘛，举个例子：
就像我们去买雪糕，我们需要买10根雪糕，带着买10根雪糕的目的，我们会根据预算的不同选择买那种雪糕。如果我们的预算充足，我们可以买好一点的雪糕巧乐兹。 如果我们的预算不是那么充分，我们也可以买老冰棍啊。

2.1.1 应用场景

2.1.1.1.编写一个接口，根据入参的不同执行不同的业务逻辑

当我们接收到这样一个需求时，我们可以用策略模式来设计我们的接口。
例如我们需要写一个根据入参的不同查询不同的数据的接口，我们可以这样设计：

我们完全可以选择上面这种这几而避免用过多的if else来实现，并且当客户新增参数时，我们只需新增一个QueryService的实现类，然后做出相应的配置即可。

但是如果我们使用if else的方式来做的话，我们会造成如下后果：代码量累计过多，可读性下降，修改原有代码会增加测试的工作量(需要回归测试)，后期难以维护。

好啦，下面我们再复习下策略模式：
策略模式定义了算法族，将具体的算法各自封装起来，让他们之间可以相互替换，并让算法的变化独立于使用算法的客户。