Question

我想知道，主要是作为一种行业标准方法，或者作为一种明确的最佳实践方法，如果通常会对条件进行编程。

我发现自己经常使用下面的第一种方法，从来没有真正遇到过问题。但我仍然想知道何时应该使用它。

这只是一个例子来说明我的意思，它不应被视为通常使用的比较的正常复杂性。

示例

public class Validation {
   int x = 5,
       y = 10,
       z = 100,
       a = 1;

    public void compare() {
        if (x < y) {
            // Do Something
            if (y < z) {
                // Do Something
                if (z < a) {
                    System.out.println("Whatever");
                }
            }
        }
    }

    public void alternate() {
        if (compareNumbers(x, y)) {
            // Do something
            if (compareNumbers(y, z)) {
                // Do something
                if (compareNumbers(z, a)) {
                    System.out.println("Whatever");
                }

            }
        }
    }

    public boolean compareNumbers(int a, int b) {
        return a < b;
    }
}

哪一种更好的做法？这是一个非常简单的例子，想象你通常会使用更复杂的验证。

如果'alternate'更好，那么必须调用比较方法/函数多少次才能更好？

如果这属于StackExchange，我很抱歉，我不太确定要将其发布到哪一个。

要将范围缩小到StackOverflow，可以说这个问题仅适用于Java。虽然可以欣赏一般的编程视图/响应。

Answer 1

将代码提取到方法有几个好处：

使代码可读
它允许轻松更改方法的实现
它允许对此特定方法进行单元测试

如果您的所有方法都是将<运算符应用于这两个参数，我会说上述三个原因都不适用，并且您过于复杂。只需使用<方法，并在需要使用更多“肉”的测试时重构代码。

Answer 2

没有＆＃34;行业标准＆＃34;对于这种事情。有充分的理由。

至于a < b是否比compareNumbers(a, b)更好......答案取决于实际情况。

在您的示例中，大多数人都同意a < b更好¹。但这是一个人为的例子，对于其他（更现实的）例子，答案可能不同。

关于在代码中表达算法等的最佳方式的各种其他问题也是如此。像这样的问题很少有一个客观正确的答案。这通常是一个意见问题......而且背景确实很重要。

但最重要的是，这是唯一真正的行业标准＆＃34;这是：

使用您的专业知识，技能和判断力。

......这意味着：

思考每个特定问题并找到合适的（合理的）解决方案，
考虑编码工作量，可读性²，可靠性，解决方案的可维护性，
考虑情况的经济学;即在花费的时间与抛光之间进行权衡。你的代码和时间花在做其他事情上，比如实现功能，测试，编写文档，满足截止日期。

^{1 - 如果我必须向下滚动几页来检查compareNumbers正在做什么，这是一个障碍......与使用<的内联比较相比。现在，如果比较背后有更深层次的语义，那么方法抽象可能是一件好事，特别是如果在解释语义的方法中有注释。但在此示例中，compareNumbers(a, b) 的语义更少而不是a < b。}

^{2 - 另一个答案指出（没有支持证据）将方法抽象到方法可以提高可读性。这是一种严重的过度简化，而且往往是错误的。这是重要的技术......但并不总是正确的。}

Answer 3

根据我的个人经验，如果我知道条件总是保持不变，我会使用原始比较，但是如果有任何需要改变条件的机会，我会使用备用。这样我就不必回去并单独替换每一个条件。

Answer 4

在打破这些方法的基础上，我知道你的例子只是一个简单的例子，但我不是专注于评估，而是专注于任务并组织这样的代码：

     public void someMethodThatCares(int x, int y, int z, int a)
     {
         taskXY(x, y);
     }

     public void taskXY(int x, int y)
     {
         if (x < y)
         {

             taskYZ(y, z);
         }

     }

     public void taskYZ(int y, int z)
     {
         if (y < z)
         {

             taskZA(z, a);
         }
     }

     public void taskZA(int z, int a)
     {
         if (z < a)
         {

         }
     }

现在，您可以根据需要构建依赖项，独立测试每个功能，以干净的方式维护逻辑，并根据需要重用它。

Answer 5

实际上，我专注于代码的复杂性以及该逻辑在我的项目中的重要性。因此，我可能会使用同一类中的所有替代方案，甚至可以使用相同的方法。

Answer 6

我建议四人帮阅读Design Patterns，了解更多关于如何决定的信息。对于每个问题，方法都会有所不同。例如，如果您需要编写单独检查每个变量的多个程序，第一个程序执行少于检查，第二个程序执行大于检查，第三个执行等于检查，则可能有意义使用每个变量的策略设计模式这些案例可以防止创建多个程序并使用Factory创建者来决定使用哪个策略。工厂模式可以根据用户输入或其他方法决定在运行时使用哪一个。

如何对条件进行编程，何时一种方法变得比另一方更好

6 个答案: