这可能是把策略模式讲的最通俗易懂得文章了

周末无事，窝在家里面看《权力的游戏第八季》，看的很是津津有味，虽然感觉有一点点要烂尾，但是我还是忍不住要去看到底谁可以坐上铁王座。

女朋友在一旁点外卖，好像是在使用优惠的时候遇到了一点点小问题。

 

 

 

 

 

 

 

 

 

策略

策略，指的是可以实现目标的方案集合，在某些特定情况下，策略之间是可以相互替换的。

比如我们在外卖平台上看到的这些优惠。满减、会员和红包等，每一个大项优惠都具体包含了多个优惠方案。如满减活动中，可以同时有满20减15、满50减30等。会员包含普通会员、超级会员等。

每一个优惠方式下面的多个优惠方案，其实都是一个策略。这些策略之间是相互排斥、可替换的。并且是有一定的优先级顺序的。

 

如上图，一笔订单中共使用到了4种优惠，可以说我们组合使用了四种优惠策略。

 

 

 

 

如何计算金额

我们先拿点外卖中会员折扣活动举例子来说明一下吧。外卖平台上的某家店铺为了促销，设置了多种会员优惠，其中包含超级会员折扣8折、普通会员折扣9折和普通用户没有折扣三种。

我们希望用户在付款的时候，根据用户的会员等级，就可以知道用户符合哪种折扣策略，进而进行打折，计算出应付金额。

代码中可以这样写：

 

以上代码比较简单，就是在代码中通过if-else进行逻辑判断，不同类型的会员享受不同的折扣价。

 

 

再增加一种会员类型

这个时候，平台增加了一种店铺专属会员，这种会员可以专享某一个店铺菜品的7折优惠，那么代码又要改成以下这样：

 

会员折扣变化

后面，随着业务发展，新的需求要求专属会员要在店铺下单金额大于30元的时候才可以享受优惠。代码就需要再次修改：

 

接着，又有一个变态的需求，如果用户的超级会员已经到期了，并且到期时间在一周内，那么就对用户的单笔订单按照超级会员进行折扣，并在收银台进行强提醒，引导用户再次开通会员，而且折扣只进行一次。代码需要做如下修改：

 

 

 

 

 

为什么要使用策略模式

以上代码，所有关于会员折扣的代码全部都写在了一个calPrice方法中，增加或者减少一种会员类型，就需要改动到整个方法。还要考虑这种会员折扣的优先级问题。

除了增加会员类型外，其中任何一种会员类型的折扣策略发生变化，也需要改动到整个算法。

这就会导致这个算法越来越臃肿，进而得到的后果就是代码行数越来越多，开发人员改动一点点代码都需要把所有功能全部都回归一遍。

就比如说我只是把超级会员的折扣从8折改为8.5折，这时候因为代码都在一起，那就需要在上线的时候对于会员折扣的所有功能进行回归。

 



久而久之，这段代码就变成了一段谁都不愿改，谁都不敢改的代码。俗称"屎山"。这种代码会使代码有极低的可读性、可维护性、可扩展性，并且回归成本较高。

 

 

 

 

策略模式

我们说日常生活中，我们要实现目标，有很多方案，每一个方案都被称之为一个策略。在软件开发中也常常遇到类似的情况，实现某一个功能有多个途径，此时可以使用一种设计模式来使得系统可以灵活地选择解决途径，也能够方便地增加新的解决途径。这就是策略模式。

策略模式(Strategy Pattern)，指的是定义一系列算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化。

特别说明一下，策略模式只适用管理一组同类型的算法，并且这些算法是完全互斥的情况。也就是说任何时候，多个策略中只有一个可以生效的那一种。如满减中的满20减10与满30减20之间；普通会员折扣与超级会员折扣之间等。

在策略模式中，定义一些独立的类来封装不同的算法，每一个类封装一个具体的算法，在这里，每一个封装算法的类我们都可以称之为策略(Strategy)，为了保证这些策略的一致性，一般会用一个抽象的策略类来做算法的定义，而具体每种算法则对应于一个具体策略类。

要实现策略模式，肯定离不开策略。如前面提到的超级会员、普通会员、专属会员等的折扣其实都是策略。完全可以通过策略模式来实现。

实现策略模式主要包含的角色如下：

 

抽象策略类

先定义一个接口，这个接口就是抽象策略类，该接口定义了计算价格方法，具体实现方式由具体的策略类来定义。

 

具体策略类

针对不同的会员，定义三种具体的策略类，每个类中都分别实现计算价格方法。

 

 

上面几个类的定义体现了封装变化的设计原则，不同会员的具体折扣方式改变不会影响到其他的会员。

定义好了抽象策略类和具体策略类之后，我们再来定义上下文类，所谓上下文类，就是集成算法的类。这个例子中就是收银台系统。采用组合的方式把会员集成进来。

 

这个Cashier类就是一个上下文类，该类的定义体现了多用组合，少用继承、针对接口编程，不针对实现编程两个设计原则。

由于这里采用了组合+接口的方式，后面我们在推出其他类型会员的时候无须修改Cashier类。只要再定义一个类实现Buyer接口 就可以了。

除了增加会员类型以外，我们想要修改某个会员的折扣情况的时候，只需要修改该会员对应的策略类就可以了，不需要修改到其他的策略。也就控制了变更的范围。大大降低了成本。

下面定义一个客户端来测试一下：

 

输出结果：

//普通会员商品的最终价格为：270.0
//超级会员商品的最终价格为：240.0

从上面的示例可以看出，策略模式仅仅封装算法，提供新的算法插入到已有系统中，策略模式并不决定在何时使用何种算法。在什么情况下使用什么算法是由客户端决定的。

 

 

 

 

策略模式的优缺点

策略模式可以充分的体现面向对象设计原则中的封装变化、多用组合，少用继承、针对接口编程，不针对实现编程等原则。

策略模式具有以下特点：

• 策略模式的关注点不是如何实现算法，而是如何组织、调用这些算法，从而让程序结构更灵活，具有更好的维护性和扩展性。
• 策略模式中各个策略算法是平等的。对于一系列具体的策略算法，大家的地位是完全一样的，正因为这个平等性，才能实现算法之间可以相互替换。所有的策略算法在实现上也是相互独立的，相互之间是没有依赖的。所以可以这样描述这一系列策略算法：策略算法是相同行为的不同实现。
• 运行期间，策略模式在每一个时刻只能使用一个具体的策略实现对象，虽然可以动态地在不同的策略实现中切换，但是同时只能使用一个。

如果所有的具体策略类都有一些公有的行为。这时候，就应当把这些公有的行为放到共同的抽象策略角色Strategy类里面。当然这时候抽象策略角色必须要用Java抽象类实现，而不能使用接口。

 

但是，编程中没有银弹，策略模式也不例外，他也有一些缺点，我们先来回顾总结下他的优点：

• 策略模式提供了对“开闭原则”的完美支持，用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。
• 策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码移到父类里面，从而避免代码重复。
• 使用策略模式可以避免使用多重条件(if-else)语句。多重条件语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重条件语句里面，比使用继承的办法还要原始和落后。

但同时，他也有如下缺点：

• 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。这种策略类的创建及选择其实也可以通过工厂模式来辅助进行。
• 由于策略模式把每个具体的策略实现都单独封装成为类，如果备选的策略很多的话，那么对象的数目就会很可观。可以通过使用享元模式在一定程度上减少对象的数量。

 

 

 

 

最后，附上本文内容的思维导图：

转载于:https://www.cnblogs.com/CQqf2019/p/10935401.html