答应我你哪儿也不去，好吗？

事实上，那时候我特别喜欢if/else系列写作，这是一个SAO操作，比如一个简单的理解好的栗子:

一般来说，我们正常的后台管理系统有所谓角色的概念。不同的管理员拥有不同的权限，可以执行不同的操作，例如

例如，当用户进来时，我们需要根据不同用户的角色判断他们有什么行为。这时，SAO代码出现:

所以当系统中有几十个字符时，这几十个if/else嵌套可以说是非常酸和新鲜的...这很优雅，别人很难读懂。其次，如果它更复杂或者如果你想增加更多的条件，它很难扩展。和代码改变，旧的功能必须重新测试，而不是疯狂...

所以，如果你不看以下内容，你通常如何处理这些令人头痛的if/else语句？

< p >让我们简要讨论几种改进方法，如果/否则停止使用

< p >在什么角色可以做什么和什么事情可以做之间有一个明显的对应关系，所以为什么不使用学到的枚举？

首先定义了一个通用接口RoleOperation，它指示不同的角色可以做什么:

接下来，我们将把不同角色的情况移交给枚举类，并定义一个枚举类Roleenum:

下一个调用变得异常简单，只有一行代码，如果/否则就没了:

，这样，如果我想在将来扩展条件，我只需要向枚举类添加代码，而不是更改以前的代码。不是很稳定吗？

< p >除了使用枚举来消除if/else，工厂模式还可以实现

的不同分支做不同的事情，这显然提供了使用工厂模式的机会。我们只需要分别定义不同的情况，然后转到工厂类进行聚合。

首先，对于不同的角色，分别定义他们的业务类别:

下一步，编写另一个工厂类RoleFactory来聚合上述不同的角色:

接下来，在上述工厂的帮助下，业务代码调用只需要一行代码，并且如果/否则也被消除:

这样，也便于将来扩大条件。只需要添加新代码，不需要移动以前的业务代码。这与“开放封闭原则”非常一致。

< p >来吧，我们继续。除了工厂模式，战略模式也可以尝试

战略模式和工厂模式在写作上没有太大区别！

在上述工厂模式代码的基础上，根据策略模式的指导思想，我们还创建了一个所谓的策略上下文类，这里命名为RoleContext:

显然，上面传递的参数操作意味着不同的“策略”。通过在业务代码中引入不同的角色，我们可以得到不同的操作结果:

，

好吧，我们先来谈谈。这篇文章只是一条建议。它用一个极其简单的例子来制作一个样本。然而，它的思想可以广泛应用于实际和复杂的业务和场景。这个想法真的很重要！在编写代码之前，我们仍然需要更多地考虑是否有更可扩展的编写方法。