想起当时的事情,其实我也迷上了if/else的连作,SAO操作着,例如可以举出容易理解的简单栗子
通常,我们的成功后台管理系统具有角色概念,管理员的权限不同,可以执行的操作也不同。 例如,您可以
系统管理员( role _ root _ admin ) :具有a操作权限 订单管理员( role _ order _ admin ) :具有b操作权限 一般使用者( role _ normal ) :具有c作业权限 例如,用户必须进入,并根据用户角色确定他们的行为。 这时,SAO代码出现了
这样,如果系统有几十个角色的话,那几十个if/else嵌套可以说是非常酸酸……这不是非常优雅,别人读起来很麻烦的第二个是,以后如果想要更复杂、追加条件的话,代码就不能扩展,而且代码也会变化
如何处理这些棘手的if/else语句?
当然有人说用switch/case写的话会优雅吗? 答案是:“没有毛的区别!
接下来简单地说几个改良方法,让if/else不要离开世界
为什么会有列举 什么样的角色能做什么,这明显是有对应关系的,为什么不用学过的列举呢?
首先,定义通用接口RoleOperation以说明可以执行多种角色的操作
然后,将不同角色的情况传递给枚举类,并定义对不同角色具有不同权限的枚举类RoleEnum
然后,调用变得非常简单,代码只需要一行,if/else也消失了
然后,如果今后想要扩展条件,就不要更改以前的代码,而是在枚举类中添加代码,这样不稳定吗
除了在枚举中删除if/else外,还可以实现工厂模型
既然有工厂模型,为什么不用呢 为每个分支做不同的事情,明显提供使用工厂模型的契机,我们可以个别定义情况,集中到工厂级别。
首先,为不同的角色分别定义业务类
接下来,您将创建一个工厂类RoleFactory来聚合上述不同的角色
在以下工厂中,业务代码调用只需要一行,if/else也已删除
这样的话,今后扩展条件也很容易,只要追加新的代码,就不需要移动以前的业务代码,非常符合“开关原则”。
现在,让我们不仅尝试工厂模式,还尝试战略模式
为什么有战略模式 战略模式和工厂模式实际上没有区别!
基于以上工厂模型代码,基于战略模型的指导思想,我们也创建战略上下文类。 现在,我们将其命名为RoleContext
0
很明显,上面传递的参数operation表示不同的“策略”。 戴尔通过将不同的角色应用于业务代码,可以获得不同的操作结果
共同学习
现在,让我们谈谈。 本论文只是抛砖引玉,用非常简单的例子做了样本,其思想可以广泛应用于实际的复杂业务和场景,思想在写出真正重要的代码之前应该考虑是否有更加具有扩展性的写法!