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的方式来做的话,我们会造成如下后果:代码量累计过多,可读性下降,修改原有代码会增加测试的工作量(需要回归测试),后期难以维护。
好啦,下面我们再复习下策略模式:
策略模式定义了算法族,将具体的算法各自封装起来,让他们之间可以相互替换,并让算法的变化独立于使用算法的客户。
演示结果:
项目地址: