如何看待“反如果”运动及其目标？
我有一个开发人员近 3 年，在我的编程习惯中经常使用 if-else 或 if-else if 语句。
今天，我发现了这个链接。
我放在这里的一个明显的示例
public void doSomthing(String target, String object){
//validate requests
if(target != null && target.trim().length() < 1){
//invalid request;
}
//further logic
}
现在，我在所有地方、图书馆都看到了这种检查。所以，我想讨论一下这样一个运动的价值。
请告诉我您的看法。
I have a developer for last 3 years, have been using if-else or if-else if statements a lot in my programing habit.
And today, I found This link.
One obvious sample i put here
public void doSomthing(String target, String object){
//validate requests
if(target != null && target.trim().length() < 1){
//invalid request;
}
//further logic
}
Now, I have seen this sort of check all over the places, libraries. So, I wanted to have a discussion about the worthiness of such a movement.
Please let me know your views.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
文章主张反对使用
if来模拟多态性。换句话说，如果您发现自己正在切换或测试对象是否属于某种类型，那么您就做错了——您应该让类型系统为您做这件事。The article is advocating against the use of
ifto simulate polymorphism. In other words, if you find yourself switching or testing if your object is of some type, you're doing it wrong -- you should let the type system do that for you.我想指出的一件事是链接的文章不是反如果的。它是基于反类型的逻辑。假设每种动物都是一个类型/类别。
在我看来，这是令人震惊的。不是因为它有一串 if，而是因为条件的方式是特定于类型的。
相反，每个动物都可以实现自己的 eat() 方法。现在上面的代码就变成了
这样。由于没有 if 语句，因此不会出现逻辑错误。此外，添加 Animal 的新实现不需要更改此代码。在第一个示例中，添加大象需要更改代码。
One thing I'd like to point out is that the linked article isn't anti-if. It is anti-type-based-logic. Assume each animal is a type/class.
this is egregious IMO. Not because it has a string of ifs, but because the way the conditionals are type-specific.
Instead, each animal could implement its own eat() method. Now the code above becomes
and that's that. Since there are no if statements there's no chance of a logic error. Further, adding a new implementation of Animal doesn't require this code to be changed. In the first example, adding an Elephant requires code to be changed.
我认为反假设运动的目的不应该是消除所有假设。从文章中的代码来看，它似乎违背了可以通过利用多态性来实现的构造。在您的示例中，可以使用 if 子句。
I don't think the anti-if campaign should aim at removing all
ifs. From the code in the article it appears that it is against constructs that can be otherwise implemented via utilizing polymorphism. In your example it is fine to use an if-clause.本文并不是在讨论永远不要使用
ifs。它们是程序控制所必需的。话虽如此，在某些情况下，避免一系列 if 语句是有意义的，这就是我认为“反 if”运动的意义所在。This article is not talking about never using
ifs. They are needed for program control. That being said there are cases that it makes sense to avoid chains of if statements and that is what I believe the "anti if" movement is about.我必须仔细阅读它。不幸的是，该网站上似乎有一些未经证实的说法，例如“肯特·贝克加入反 IF 运动”。
IF 语句增加了代码的复杂性，这是事实。 try/catch 块、循环和任何条件表达式也是如此。笼统地声明他们是坏的/邪恶的/等等。这不是一个好的形式。请参阅：编程中的任何东西真的是邪恶的吗？
我不能看看他的解决方案在哪里真正消除了对条件逻辑的需求。最重要的是，只要能让代码更容易维护，就去做。
I'd have to read up on it. Unfortunately, it appears that there are some unsubstantiated claims on the site like "Kent Beck joins the Anti-IF campain".
IF statements to increase the complexity of code, that is true. So do try/catch blocks, loops, and any conditional expression. To make a blanket statement that they are bad/evil/etc. is not good form. See: Is anything in programming truly evil?
I can't see where his solutions truly remove the need for conditional logic. The bottom line is whatever makes the code easier to maintain, do it.
你举的例子似乎有些道理。但是，您不应该默默地让它失败或返回 null 或其他内容，而应在无效时抛出异常。更好的是使用断言。
使用 ifs 来测试对象类型是一种不好的做法，而不是更多地考虑你的类和关系。在像 Java 这样的静态类型语言中， if (a instanceof b) 不应该成为一直执行的规范。
The example you give seems somewhat reasonable. However you should not silently let it fail or return null or something else but throw an exception when it is invalid. And better yet is to use assertions.
Using ifs to test object types is kind of bad practice, rather than that think about your classes and relations more. In a statically typed language like Java that shouldnt be the norm to do if (a instanceof b) all the time.