使用策略模式代替嵌套的多层if-else
–
后台在开发的过程中，需要进行各种逻辑判断，来判断某个按钮是否展示，某个操作是否允许。
所以嵌套了很多if-else判断，看起来很是头痛。修改了起来也要各方面考虑，防止逻辑错误，进行影响。
如图：
之前一直不知道会有怎样的处理方式更好。
先简介一下，这戏需要进行的逻辑判断：
-
判断当前用户是否有权限
- 判断用户状态，
- 判断时间等
- 其他
-
判断此条信息状态是否允许这个操作
- 此条信息其他信息的影响
- etc
今天突然看到一篇文章，介绍策略模式，感觉找到了救星。但是也想到，自己好久不去主动学习，之前学过的东西，也没有好好利用，因为策略在某些地方就是自己之前知道的组合啊。 对象的继承，属性的组合等。应该触类旁通啊。
以下是摘要：
对于业务开发来说，业务逻辑的复杂是必然的，随着业务发展，需求只会越来越复杂，为了考虑到各种各样的情况，代码中不可避免的会出现很多if-else。
一旦代码中if-else过多，就会大大的影响其可读性和可维护性。首先可读性，不言而喻，过多的if-else代码和嵌套，会使阅读代码的人很难理解到底是什么意思。尤其是那些没有注释的代码。
其次是可维护性，因为if-else特别多，想要新加一个分支的时候，就会很难添加，极其容易影响到其他的分支。
笔者曾经看到过一个支付的核心应用，这个应用支持了很多业务的线上支付功能，但是每个业务都有很多定制的需求，所以很多核心的代码中都有一大坨if-else。
每个新业务需要定制的时候，都把自己的if放到整个方法的最前面，以保证自己的逻辑可以正常执行。这种做法，后果可想而知。
其实，if-else是有办法可以消除掉的，其中比较典型的并且使用广泛的就是借助策略模式和工厂模式，准确的说是利用这两个设计模式的思想，彻底消灭代码中的if-else。
本文，就结合这两种设计模式，介绍如何消除if-else，并且，还会介绍如何和Spring框架结合，这样读者看完本文之后就可以立即应用到自己的项目中。
本文涉及到一些代码，但是作者尽量用通俗的例子和伪代码等形式使内容不那么枯燥。
恶心的if-else
假设我们要做一个外卖平台，有这样的需求：
1、外卖平台上的某家店铺为了促销，设置了多种会员优惠，其中包含超级会员折扣8折、普通会员折扣9折和普通用户没有折扣三种。
2、希望用户在付款的时候，根据用户的会员等级，就可以知道用户符合哪种折扣策略，进而进行打折，计算出应付金额。
3、随着业务发展，新的需求要求专属会员要在店铺下单金额大于30元的时候才可以享受优惠。
4、接着，又有一个变态的需求，如果用户的超级会员已经到期了，并且到期时间在一周内，那么就对用户的单笔订单按照超级会员进行折扣，并在收银台进行强提醒，引导用户再次开通会员，而且折扣只进行一次。
后面看原文吧。