让你的软件更优秀的方法之优化if-else

William
2021-04-28 / 0 评论 / 8 阅读 / 正在检测是否收录...
  1. 完全不必要的Else块
  2. 值分配
  3. 前提条件检查
  4. 将If-Else转换为字典—完全避免If-Else
  5. 扩展应用程序—完全避免使用If-Else

默认图片

1、完全不必要的else块

这也许是那些初级开发人员最负罪的之一。下面的示例很好地说明了当您被认为If-Else很棒时会发生什么。

简单的if-else

只需删除else块即可简化此过程。

删除了其他

看起来更专业吧?
您会经常发现实际上根本不需要else块。像在这种情况下一样,如果满足特定条件,您想做一些事情就立即返回。

2、值分配

如果要基于提供的某些输入为变量分配新值,请停止If-Else废话-一种更具可读性的方法。

使用if-else进行值分配

尽管很简单,但是却很糟糕。首先,If-Else很容易在这里被开关取代。但是,我们可以通过完全删除else ifelse完全简化此代码。

if语句快速返回

删除else if和else,我们剩下的是清晰易读的代码。注意,我也将样式更改为快速返回而不是单返回语句-如果已经找到正确的值,继续测试一个值根本没有意义。

3、前提条件检查

大多数情况下,我发现如果提供了无效值,则继续执行方法是没有意义的。
假设我们从以前就有了DefineGender方法,要求提供的输入值必须始终为01

默认图片

在没有值验证的情况下执行该方法没有任何意义。因此,在允许方法继续执行之前,我们需要检查一些先决条件。

应用保护子句防御性编码技术,您将检查方法的输入值,然后继续执行方法。

使用保护子句检查前提条件

至此,我们确保仅在值落在预期范围内时才执行主逻辑。
现在,IF也已被三元代替,因为不再需要在结尾处默认返回“未知”。

4、将If-Else转换为字典—完全避免If-Else

假设您需要执行一些操作,这些操作将根据某些条件进行选择,我们知道稍后我们将不得不添加更多操作。

默认图片

也许有人会倾向于使用久经考验的If-Else。如果要添加一个新的操作,只是简单地增加了一个额外的问题。很简单 但是,就维护而言,此方法不是一个很好的设计。

知道我们以后需要添加新的操作后,我们可以将If-Else重构为字典。

默认图片

可读性已大大提高,并且可以更轻松地推断出此代码。
注意,仅出于说明目的将字典放置在方法内部。您可能希望从其他地方提供它。

5、扩展应用程序—完全避免使用If-Else

这是一个稍微高级的例子。

让我也快速澄清一些实际问题……这是一种更“主动”的方法。这不会是您典型的“让我只用if-else代替”的情况。现在,继续阅读。

通过用对象替换,知道何时甚至完全消除If。

通常,您会发现自己不得不扩展应用程序的某些部分。作为初级开发人员,您可能倾向于通过添加一个额外的If-Else(即else-if)语句来做到这一点。

以这个典型的例子为例。在这里,我们需要将Order实例显示为字符串。首先,我们只有两种字符串表示形式:JSON纯文本。使用的if-else在这个阶段是不是一个大问题,寿,我们可以很容易地更换else if只需if正如前面证明。

默认图片

知道我们需要扩展应用程序的这一部分,这种方法绝对是不可接受的。

上面的代码不仅违反了Open / Closed原理,而且阅读效果也不佳,并且会引起可维护性方面的麻烦。

正确的方法是遵循SOLID原则的方法-我们通过实施动态类型发现过程(在本例中为策略模式)来做到这一点。

重构此混乱热点的过程如下:

  1. 使用公共接口将每个分支提取到单独的策略类中
  2. 动态查找实现公共接口的所有类
  3. 根据输入决定执行哪种策略

将替换上面示例的代码如下所示。是的,这是更多代码的方式。它要求您了解类型发现的工作原理。但是动态扩展应用程序是一个高级主题。

我只显示将替换If-Else示例的确切部分。如果要查看所有涉及的对象,请查看此要点。

默认图片

理想情况下,类型发现和字典将发生在PrintOrder方法之外。但是无论如何,让我们快速浏览一下代码。

方法签名保持不变,因为调用者不需要了解我们的重构。

首先,获取实现通用接口的程序集中的所有类型IOrderOutputStrategy。然后,我们建立一个字典,格式化程序的displayName的名称为key,类型为value

然后从字典中选择格式化程序类型,然后尝试实例化策略对象。

最后,ConvertOrderToString调用策略对象。

1

评论 (0)

取消