4

所以我刚刚遇到了一些类似这样的代码：

checkCalculationPeriodFrequency("7D", "7D", SHOULD_MATCH);

和

checkCalculationPeriodFrequency("7D", "8D", SHOULD_NOT_MATCH);

让我们不要担心代码现在（或者实际上永远）做了什么，而是让我们担心最后一个参数 - SHOULD_MATCH 和 SHOULD_NOT_MATCH

这是我以前想过的事情，但认为这样做可能是“坏的”（因为“坏”在后现代主义世界中具有任何真正的意义）。

上面，声明了这些值（正如您可能假设的那样）：

private boolean SHOULD_MATCH = true;
private boolean SHOULD_NOT_MATCH = false;

我不记得阅读过有关“命名”传递给方法调用以简化可读性的布尔参数的内容，但这当然是有道理的（为了可读性，但它也隐藏了值是什么，即使只有一点点）。这是其他人发现的风格是 instagram 还是喜欢，soooo facebook？

4

4 回答 4

5

命名参数将有助于提高可读性，尤其是当替代方案通常类似于

checkCalculationFrequency("7D",
                          "8D",
                          true /* should match */);

这是丑陋的。拥有特定于上下文的常量可能是解决此问题的方法。

我实际上会更进一步，重新定义函数原型以接受enum：

enum MatchType {
    ShouldMatch,
    ShouldNotMatch
};

void checkCalculationFrequency(string a, string b, MatchType match);

我更喜欢这个而不是布尔值，因为它使您可以灵活地扩展函数以在MatchTypes以后接受其他函数。

于 2013-10-25T13:58:48.210 回答
3

我建议你不要这样做。

首先，对于每个对象，重新生成两个成员 SHOULD_MATCH 和 SHOULD_NOT_MATCH。这不好，因为它不是对象的行为。因此，您要使用的是，至少将其描述为 STATIC FINAL。

其次，我更喜欢使用枚举，因为您可以完全控制参数的值，即当您使用它时，您必须使用 SHOULD_MATCH 或 SHOULD_NOT_MATCH，而不仅仅是 true 或 false。这也增加了可读性。

问候。

于 2013-10-25T14:00:32.833 回答
1

这确实是为了可读性。这个想法是函数调用的读者可能不会立即知道函数调用true中的值意味着什么，但SHOULD_MATCH会立即传达含义（如果您需要查找实际值，您可以毫不费力地做到这一点）。

如果函数调用中有多个布尔参数，这将变得更容易理解：这true意味着什么？

此逻辑的下一步是为参数值创建命名对象值（例如，通过枚举）：您不能将错误的值传递给函数（例如，在三个布尔参数的示例中，没有什么能阻止我SHOULD_MATCH全部传入其中，即使该函数在语义上没有意义）。

于 2013-10-25T13:54:10.980 回答
1

这绝对不仅仅是一种风格。

我们有一个类似的系统，它以布尔值 1 或 0 的形式从开关中获取输入，这与真或假几乎相同。

在这个系统中，我们声明我们的变量 OPEN = true 和 CLOSED = false* 并将它们传递给函数，这些函数根据开关的状态执行不同的操作。现在，如果有人碰巧以不同的方式连接开关，那么我们现在在打开时获得值 0，在关闭时获得值 1。

通过命名布尔变量，我们可以轻松地调整系统，而无需更改整个逻辑。代码变得自我记录，因为开发人员可以更清楚地了解在这种情况下应该采取什么行动，而不必担心会带来什么价值。

当然，布尔值的真正目的应该在我们系统中的其他地方和它的其他地方得到很好的记录......诚实......

*（也许我们使用 OPEN，！OPEN 我忘了）

于 2013-10-25T14:04:52.180 回答