61 | 策略模式（下）：如何实现一个支持给不同大小文件排序的小程序？

哪位了解无状态的类是什么意思 ?

策略模式看着像是个工厂模式

在之前项目中，有个缓存的实现开始直接使用的redis来实现的，后来使用内存缓存替换，这样一来我使用了策略模式根据缓存key的类型，自动选择策略进行缓存。

对查表法来避免if-else很有感触，之前设计Jenkins pipeline是就是用Map来存放不同的component部署到不同server的映射关系的. 感觉策略模式的本质就是多态？

策略类膨胀的情况，小争哥有没一些最佳实践可以分享？ 业务实现上，可能一个父级策略下有多个子策略（譬如促销活动有满减/返现/立减等，满减规则下又有几种复杂的优惠策略），这时候把所有满减规则塞进一个策略类，有些偏离我们的初衷；将子策略拆分为独立的策略，策略类的数目又会急剧膨胀。 如何取舍？或者能否混合其他模式来适应这种场景？

"设计原则和思想比设计模式更加普适和重要"，被这句话一下子点醒了。可以这样说，设计原则和思想是更高层次的理论和指导原则，设计模式只是这些理论和指导原则下，根据经验和场景，总结出来的编程范式。

看到这里我感觉好多设计模式都很类似, 都是先针对接口编程, 然后再加个查表法😂

策略集合的信息也可以定义成枚举，可以放在数据库，可以放kv配置中心，等等。都是一样的道理。 策略模式是对策略的定义，创建和使用解藕。定义和创建的过程与业务逻辑关系不大，写在一起会影响可读性。 创建型模式是对创建和使用的解藕。 做什么和怎么做是应该解藕的，使用者并不关心具体的细节。 在业务逻辑中，与业务逻辑不大的代码应该放在外部。就像mvc的三层架构是业界的最佳实践。在service层调用dao层，而不是直接jdbc,因为如何操作数据库是个复杂的过程，却又与业务逻辑无关，所以单独抽出一层，代码结构变得更加清晰。 声明式编程很火。它就是把使用和内部实现原理解藕。java,spring的各种注解，声明式事务等等。使用者一个注解解决所有问题，无需关心底层。 业务逻辑无关的放在一起影响可读性，即使自己过一段时间看自己的代码也会迷惑。写代码要有用户思维，不光是提供的api满足kiss原则，内部的实现也是一样。能放在外面单位代码尽量怎么放在外面。只要能表达逻辑即可。

1.为了让调度的代码更优雅时使用。（就调度策略的代码而言，可读性高。理解结构后，阅读的心智负担低，因为调度的原理已经抽象成了共同的type查表，无需逐行检阅分支判断。像一些与持久数据相关的策略，有时为了兼容老数据或则平滑过度，无法全采用type查表，这时就需要结合if来 实现。所以采用if会让我误以为是这种场景，进而逐行检阅）。 2.感觉问反了，应该是什么场景下采用ifelse和witch。毕竟这两个的场景少些。答案是，在逻辑不复杂又不好用卫语句时采用。能用卫语句就不要ifelse。因为个人而言，看到retuern或conti能很明确跳出逻辑，else脑袋得转一下，当然这可能是个人习惯影响。但ifelse还是只在逻辑简单，没啥嵌套（一个函数内部不宜嵌套过多），且语义符合的场景用好些。 3.原则和思想毕竟是指导核心，是地图和尺子，自然是最重要的。但是不等于设计模式就比其不重要了。硬要说的话，我认为两个其实一样重要。设计模式是场景的积累，拉近了普通人与天才的差距，对我这种菜鸡来说可能比设计原则还重要。毕竟从设计原则到设计模式的出现，需要丰富经验，扎实知识和妙手偶得。如果没有设计模式的铺垫，普通人拿着设计模式的知识点要一路走上高质量代码的层级，实属不易。

很早前使用了类似策略模式的代码做了一个从各种渠道上传下载文件。（当时大学毕业，没看过策略模式，但是学过C++的多态）其实也就是基于接口而非实现编程思想。 if-else使用，如果判断较少，且未来几乎不会有新需求要再加一个else时，保持if-else即可。其他的都可以使用策略模式。不过本节demo的实例，使用range来匹配，目前看是没问题。但是如果需求变化，需要增加一个根据数据特征的动态分配排序算法，那么这里实现就麻烦了。所以需要根据具体需求来看使用什么模式...