If-Then-Else Is a Code Smell

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

在大多数情况下(甚至可能是全部情况),if-then-else 可以和必须由装饰器或者简单地另一个对象来替代。我计划写这个问题已经将近一年了,但直到今天才在我自己的代码中找到了一个完美地说明这个问题的真实案例。所以现在是时候展示并解释一下了。

看一下来自 yegor256/rultor 的类 DyTalk 和它的方法 modify()。简而言之,它会在 XML 文档没有任何修改时阻止将任何数据保存到 DynamoDB 中。这是一个有效的情况,必须进行验证,但是它的实现方式是错误的。这是它的工作原理(一个过度简化的例子):

你想知道是怎么回事?这个 if-then-else 分支功能并不适合这个对象——这就是问题所在。修改 XML 文档并将其保存到数据库是 它的功能,而如果修改指令集为空,则不保存任何内容(这与防御式编程非常相似)并不是它的功能。相反,应该有一个装饰器,它的样子应该是这样的:

现在,如果在指令列表为空的情况下,我们需要我们的交谈更聪明一些,我们就会用QuickTalk来装饰它。好处是显而易见的:DyTalk类更小,因此更具凝聚力。

但问题并不仅仅如此。我们能否从中总结出一个规则?我们能不能说每一次分叉都是不好的,应该移到类外面?那些发生在方法内部且无法转换为装饰器的分叉呢?

我建议这个简单的规则:如果将if-then-else分叉转换为装饰器是可能的,那就必须这样做。如果没有这样做,那么它就是一种代码异味。明白了吗?

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:43

sixnines availability badge   GitHub stars