
本文并不肯定或者否定哪一种写法,仅仅为大家提供一些其他的编码思路或者一些值得借鉴的点子。![]() 设计更好的软件,替换 If-Else 的 5 种方法,从入门到高级示例 If-Else 通常是一个糟糕的选择,它导致设计复杂,代码可读性差,并且可能导致重构困难。 但是,If-Else 已成为事实上的代码分支解决方案,这确实是有道理的。这是向所有有抱负的开发人员讲授的第一件事。 不幸的是,许多开发人员从来没有前进到更合适的分支策略。有些人的口头禅是:If-Else 是一把锤子,一切都是钉子。 我将向大家展示一些技巧和模式,这些技巧和模式将终结这种可怕的做法。每个示例的难度都会增加。 这也许是那些初级开发人员最负罪的之一。下面的示例很好地说明了当你被认为 If-Else 很棒时会发生什么:
![]() Simple if-else 只需删除 else` 块即可简化此过程,如下图: ![]() Removed else 看起来更专业吧?你会发现,实际上根本不需要其他块。像在这种情况下一样,你想要在满足特定条件的情况下执行某些操作并立即返回。 ![]() Value assignment with if-else 尽管很简单,但它却很糟糕。首先,If-Else 很容易在这里被开关取代。但是,我们可以通过完全删除 else 来进一步简化此代码。 ![]() If statements with fast return 如果不使用 else,则我们将剩下干净的可读代码。请注意,我也将样式更改为快速返回而不是单返回语句。如果已经找到正确的值,继续测试一个值根本没有意义。 ![]() Method without value checks 在没有价值验证的情况下执行该方法没有任何意义。因此,在允许方法继续执行之前,我们需要检查一些先决条件。 应用保护子句防御性编码技术,你将检查方法的输入值,然后继续执行方法。 ![]() Check preconditions with guard clauses 至此,我们确保仅在值落在预期范围内时才执行主逻辑。现在,IF 也已被三元代替,因为不再需要在结尾处默认返回"未知"。 ![]() 也许有人倾向于使用久经考验的 If-Else。如果添加新操作,则只需简单地添加其他内容即可。很简单 但是,就维护而言,这种方法不是一个好的设计。 知道我们以后需要添加新的操作后,我们可以将 If-Else 重构为字典。 ![]() 可读性已大大提高,并且可以更轻松地推断出该代码。注意,仅出于说明目的将字典放置在方法内部。您可能希望从其他地方提供它。 这是一个稍微高级的示例。通过用对象替换它们,知道何时甚至完全消除 If。 通常,您会发现自己不得不扩展应用程序的某些部分。作为初级开发人员,您可能会倾向于通过添加额外的 If-Else(即 else-if)语句来做到这一点。 举这个说明性的例子。在这里,我们需要将 Order 实例显示为字符串。首先,我们只有两种字符串表示形式:JSON 和纯文本。 ![]() 知道我们需要扩展应用程序的这一部分,这种方法绝对是不可接受的。 上面的代码不仅违反了"打开/关闭"原则,而且阅读得不好,还会引起可维护性方面的麻烦。 正确的方法是遵循 SOLID 原则的方法,我们通过实施动态类型发现过程(在本例中为策略模式)来做到这一点。 重构这个混乱的过程的过程如下:
替换上面示例的代码如下所示。是的,这是更多代码的方式。它要求您了解类型发现的工作原理。但是动态扩展应用程序是一个高级主题。 我只显示将替换 If-Else 示例的确切部分。如果要查看所有涉及的对象,请查看此要点。 ![]() 让我们快速浏览一下代码。方法签名保持不变,因为调用者不需要了解我们的重构。 首先,获取实现通用接口 IOrderOutputStrategy 的程序集中的所有类型。然后,我们建立一个字典,格式化程序的 displayName 的名称为 key,类型为 value。 然后从字典中选择格式化程序类型,然后尝试实例化策略对象。最后,调用策略对象的 ConvertOrderToString。 |