使用布尔参数确定值是否错误？

根据使用布尔参数确定行为是否错误？，我知道避免使用布尔参数来确定行为的重要性，例如：

原始版本

public void setState(boolean flag){
    if(flag){
        a();
    }else{
        b();
    }
    c();
}

新版本：

public void setStateTrue(){
    a();
    c();
}

public void setStateFalse(){
    b();
    c();
}

但是，使用boolean参数来确定值而不是行为的情况如何呢？例如：

public void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

我试图消除isHintOn标志并创建2个单独的函数：

public void setHintOn(){
    this.layer1.visible=true;
    this.layer2.visible=false;
    this.layer3.visible=true;
}

public void setHintOff(){
    this.layer1.visible=false;
    this.layer2.visible=true;
    this.layer3.visible=false;
}

但修改后的版本似乎难以维护，原因是：

1. 它具有比原始版本更多的代码

2. 它不能清楚地表明layer2的可见性与hint选项相反

3. 当添加一个新层（例如：layer4）时，我需要添加

   this.layer4.visible=false;
   

   和

   this.layer4.visible=true;  
   

   分别进入setHintOn（）和setHintOff（）

所以我的问题是，如果布尔参数仅用于确定值，而不用于确定行为（例如：在该参数上没有if-else），是否仍建议消除该布尔参数？

API设计应从调用方着眼于最适合API客户端的功能。

例如，如果此新API要求调用方定期编写这样的代码

if(flag)
    foo.setStateTrue();
else
    foo.setStateFalse();

那么很明显，避免使用该参数比使用允许调用者编写的API更糟糕

 foo.setState(flag);

前一个版本仅产生一个问题，然后必须在调用方解决（可能不止一次）。这既不会增加可读性，也不会增加可维护性。

在执行方面，但是，不应该决定了公共API看起来怎么样。如果像setHint参数这样的函数在实现中需要较少的代码，但是对于客户端而言，用术语setHintOn/ setHintOff看起来更容易使用的API ，则可以通过以下方式实现：

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

因此，尽管公共API没有布尔参数，但是这里没有重复的逻辑，因此，当新要求（例如问题的示例）到达时，只有一个地方可以更改。

反之亦然：如果上述setState方法需要在两个不同的代码段之间进行切换，则可以将该代码段重构为两个不同的私有方法。因此，恕我直言，通过查看内部结构来搜索用于确定“一个参数/一个方法”和“零参数/两个方法”的标准是没有意义的。但是，请看一下您希望以谁的身份来使用API​​的方式。

如有疑问，请尝试使用“测试驱动的开发”（TDD），这将迫使您考虑公共API以及如何使用它。

马丁·福勒（Martin Fowler）引用肯特·贝克（Kent Beck）推荐的单独setOn() setOff()方法，但他又说这不应被视为不可侵犯：

如果你拉从一个布尔源（原文如此）的数据，如UI控件或数据源，我宁愿有setSwitch(aValue)比

if (aValue)
  setOn();
else
  setOff();

这是一个示例，应该编写一个API来简化调用者的操作，因此，如果我们知道调用者来自何处，则应牢记该信息来设计API。这也表明，如果我们以两种方式获得呼叫者，有时我们可能会同时提供两种样式。

另一项建议是使用一个枚举值或标志类型给予true和false更好的，上下文的具体名称。在你的榜样，showHint并hideHint可能会更好。

我认为您在帖子中混合了两件事，即API和实现。在这两种情况下，我都不认为您可以一直使用严格的规则，但是您应该（尽可能）独立考虑这两件事。

让我们从API入手：

public void setHint(boolean isHintOn)

和：

public void setHintOn()
public void setHintOff()

是有效的替代方法，具体取决于对象应提供的内容以及客户端如何使用API​​。正如Doc所指出的，如果您的用户已经有一个布尔变量（来自UI控件，用户操作，外部，API等），则第一个选项更有意义，否则，您将在客户端代码上强制执行额外的if语句。但是，例如，如果您在开始过程时将提示更改为true，而在结束时更改为false，则第一个选项将为您提供以下信息：

setHint(true)
// Do your process
…
setHint(false)

而第二个选项为您提供：

setHintOn()
// Do your process
…
setHintOff()

哪个IMO更具可读性，因此在这种情况下，我将选择第二个选项。显然，没有什么可以阻止您同时提供这两种选择（或者，例如，可以使用Graham所说的枚举，如果这样做更有意义）。

关键是您应该基于对象应该做什么以及客户端将如何使用它来选择API，而不要基于您将如何实现它。

然后，您必须选择如何实现公共API。假设我们选择了这些方法setHintOn，setHintOff并将它们作为我们的公共API，并且它们与您的示例一样共享此通用逻辑。您可以通过私有方法（从Doc复制的代码）轻松抽象此逻辑：

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

相反，假设我们选择setHint(boolean isHintOn)了一个API，但由于某些原因，将提示On设置为Off完全不同，因此可以反转您的示例。在这种情况下，我们可以按以下方式实现它：

public void setHint(boolean isHintOn){
    if(isHintOn){
        // Set it On
    } else {
        // Set it Off
    }    
}

甚至：

public void setHint(boolean isHintOn){    
    if(isHintOn){
        setHintOn()
    } else {
        setHintOff()
   }    
}

private void setHintOn(){
   // Set it On
}

private void setHintOff(){
   // Set it Off 
}

关键是，在这两种情况下，我们都首先选择了公共API，然后对实现进行了调整以适合所选的API（以及我们所拥有的约束），而不是相反。

顺便说一句，我认为您所链接的关于使用布尔参数确定行为的帖子也是如此，也就是说，您应该根据您的特定用例而不是某些硬性规则来决定（尽管在这种特定情况下通常是正确的做法将其分解为多种功能）。

首先，代码不会自动减少可维护性，只是因为代码会更长一些。清晰至关重要。

现在，如果您实际上只是在处理数据，那么您拥有的是布尔属性的二传手。在这种情况下，您可能只想直接存储该值并得出层的可见性，即

bool isBackgroundVisible() {
    return isHintVisible;
}    

bool isContentVisible() {
    return !isHintVisible;
}

^{（我已经自由地给层赋予了实际的名称-如果您在原始代码中没有此名称，那么我将从此开始）}

这仍然使您面临是否有setHintVisibility(bool)方法的问题。就个人而言，我建议将其替换为showHint()和hideHint()方法-两者都将非常简单，并且在添加图层时无需更改它们。但是，这不是明确的对/错。

现在，如果调用该函数实际上应该更改这些图层的可见性，那么您实际上就有了行为。在这种情况下，我绝对会建议使用单独的方法。

在第二个示例中，布尔参数很好。正如您已经知道的那样，布尔参数本身并不是问题。这是基于标志的切换行为，这是有问题的。

但是第一个示例还是有问题的，因为命名指示了setter方法，但是实现似乎有所不同。因此，您具有行为切换反模式和一个误导性的方法。但是，如果该方法实际上是一个常规的setter（不进行行为切换），则不会有问题setState(boolean)。有两种方法，setStateTrue()并且setStateFalse()仅仅是不必要的复杂事情没有好处。

解决此问题的另一种方法是引入一个对象来表示每个提示，并让该对象负责确定与该提示关联的布尔值。这样，您可以添加新的排列，而不仅仅是具有两个布尔状态。

例如，在Java中，您可以执行以下操作：

public enum HintState {
    SHOW_HINT(true, false, true),
    HIDE_HINT(false, true, false);

    private HintState(boolean layer1Visible, boolean layer2Visible, boolean layer3Visible) {
         // constructor body and accessors omitted for clarity
    }
}

然后，您的呼叫者代码将如下所示：

setHint(HintState.SHOW_HINT);

您的实现代码如下所示：

public void setHint(HintState hint) {
    this.layer1Visible = hint.isLayer1Visible();
    this.layer2Visible = hint.isLayer2Visible();
    this.layer3Visible = hint.isLayer3Visible();
}

这使实现代码和调用者代码保持简洁，以换取定义新的数据类型，该数据类型将强类型的命名意图清楚地映射到相应的状态集。我认为这更好。

所以我的问题是，如果布尔参数仅用于确定值，而不用于确定行为（例如：在该参数上没有if-else），是否仍建议消除该布尔参数？

当我对这种事情有疑问时。我想描绘一下堆栈跟踪的样子。

多年以来，我从事一个PHP项目，该项目使用的功能与setter和getter相同。如果传递null，它将返回该值，否则进行设置。和一起工作很恐怖。

这是一个堆栈跟踪的示例：

function visible() : line 440
function parent() : line 398
function mode() : line 384
function run() : line 5

您不了解内部状态，这使调试变得更加困难。还有一堆其他的负面影响，但尝试看看有值的详细功能名称和清晰度当函数执行一个单一的动作。

现在，根据布尔值对具有A或B行为的函数的堆栈跟踪进行操作。

function bar() : line 92
function setVisible() : line 120
function foo() : line 492
function setVisible() : line 120
function run() : line 5

如果你问我，那真令人困惑。同一setVisible行产生两个不同的跟踪路径。

回到您的问题。尝试描绘堆栈跟踪的外观，如何与人交流发生了什么，并问问自己是否在帮助未来的人调试代码。

这里有一些提示：

• 一个清晰的函数名，它隐含了意图，而无需知道参数值。
• 一个功能执行一个动作
• 该名称表示突变或不可变行为
• 解决与语言和工具的调试能力相关的调试挑战。

有时代码在显微镜下看起来过多，但是当您拉回更大的图片时，一种极简主义的方法会使它消失。如果您需要将其突出以进行维护。添加许多小的功能可能会感到过于冗长，但是当在较大的上下文中广泛使用时，它会提高可维护性。

在几乎每种情况下，您都将boolean参数作为标志传递给方法以更改某些对象的行为时，应该考虑一种更显式且类型安全的方法。

如果仅使用Enum表示状态的，就可以提高代码的理解力。

本示例使用Node来自的类JavaFX：

public enum Visiblity
{
    SHOW, HIDE

    public boolean toggleVisibility(@Nonnull final Node node) {
        node.setVisible(!node.isVisible());
    }
}

总是比在许多JavaFX对象上都好：

public void setVisiblity(final boolean flag);

但我认为.setVisible()，.setHidden()对于标志为a 的情况，这是最好的解决方案，boolean因为它是最明确且最不冗长的。

对于具有多个选择的对象，以这种方式执行此操作尤为重要。EnumSet仅仅因为这个原因而存在。

埃德·曼（Ed Mann）在这个主题上有一篇非常好的博客文章。我正好解释他的话，所以为了避免重复，我只会在他的博客文章中发布一个链接，作为此答案的附录。

在确定用于传递（布尔）参数的某些接口的方法与不使用该参数的重载方法之间进行选择时，请查看使用方客户端。

如果所有用法都将传递恒定值（例如，true，false），则说明过载。

如果所有用法都传递一个变量值，则表明该方法具有参数方法。

如果这两种极端都不适用，则意味着存在多种客户端使用方式，因此您必须选择是支持两种形式，还是使一种类型的客户端适应另一种类型（对他们而言，这是不自然的）。

设计有两个注意事项：

• API：您提供给用户的界面是什么，
• 实施：清晰度，可维护性等。

它们不应混为一谈。

完全可以：

• API委托中有多个方法可实现一个实施，
• API会根据情况将一个方法分配给多个实现。

因此，任何试图通过实现设计的成本/收益平衡API设计的成本/收益的论点都是可疑的，应仔细研究。

在API方面

作为程序员，我通常会偏爱可编程API。当我可以转发一个值时，代码比需要一个if/ switch语句来确定要调用哪个函数的代码要清晰得多。

如果每个函数期望不同的参数，则后者可能是必需的。

因此，就您而言，单一方法setState(type value)似乎更好。

然而，没有什么比无名更糟true，false，2，等......这些神奇的价值观对自己没有任何意义。避免原始痴迷，并接受强类型。

因此，从API POV，我想：setState(State state)。

在实施方面

我建议您做任何容易的事情。

如果方法很简单，则最好保持在一起。如果控制流比较复杂，则最好用多种方法将其分开，每种方法都处理一个子案例或管道的一个步骤。

最后，考虑分组。

在您的示例中（添加了空格以提高可读性）：

this.layer1.visible = isHintOn;
this.layer2.visible = ! isHintOn;
this.layer3.visible = isHintOn;

为什么要layer2逆势而上？它是功能还是错误？

可能有两个列表[layer1, layer3]和[layer2]，并有一个明确的名称指示将它们分组在一起的原因，然后在这些列表上进行迭代。

例如：

for (auto layer : this.mainLayers) { // layer2
    layer.visible = ! isHintOn;
}
for (auto layer : this.hintLayers) { // layer1 and layer3
    layer.visible = isHintOn;
}

该代码不言自明，很明显为什么会有两个小组并且他们的行为不同。

setOn() + setOff()与vs set(flag)问题分开，我将仔细考虑布尔类型是否最好。您确定永远不会有第三个选择吗？

可能值得考虑使用枚举而不是布尔值。除了允许扩展性之外，这还使得更难以错误的方式获取布尔值，例如：

setHint(false)

与

setHint(Visibility::HIDE)

有了枚举，当有人决定需要“如果需要”选项时，扩展起来会容易得多：

enum class Visibility {
  SHOW,
  HIDE,
  IF_NEEDED // New
}

与

setHint(false)
setHint(true)
setHintAutomaticMode(true) // New

根据...，我知道避免使用布尔参数确定行为的重要性

我建议重新评估这些知识。

首先，在链接的SE问题中，我看不到您提出的结论。他们主要讨论的是在方法调用的多个步骤中转发参数，对参数的评估在链的最下方。

在您的示例中，您正在对方法中的参数进行评估。在这方面，它与任何其他种类的参数完全没有区别。

通常，使用布尔参数绝对没有错。显然，任何参数都可以决定行为，或者为什么首先要拥有它？

定义问题

您的标题问题是“ [...]错误吗？” -但是“错误”是什么意思？

根据C＃或Java编译器，这没错。我确定您知道这一点，但这不是您要的。恐怕除此之外，我们对n程序员的n+1看法也不同。这个答案提出了“ 清洁代码”这本书要说的内容。

回答

通常，“ 干净代码”强烈反对函数参数：

争论很难。他们具有很大的概念力。[...]我们的读者每次看到它时都必须对它进行解释。

这里的“读者”可以是API使用者。也可以是下一个编码器，他们尚不知道此代码的功能-一个月后可能会成为您。他们将分别通过2个功能，或者两次通过1个功能，一次牢记true一次false。
简而言之，请使用尽可能少的参数。

标志参数的具体情况稍后将直接解决：

标志参数很丑陋。将布尔值传递给函数是一种非常糟糕的做法。它立即使该方法的签名复杂化，大声宣称此功能可以完成多项工作。如果标志为true，则执行一件事，如果标志为false，则另一件事！

为了直接回答您的问题：
根据Clean Code，建议消除该参数。

附加信息：

您的示例非常简单，但是即使在那儿，您也可以看到传播到代码的简单性：无参数函数仅执行简单的赋值，而另一个函数必须执行布尔算术才能达到相同的目标。在此简化示例中，这是微不足道的布尔运算，但在实际情况下可能会非常复杂。

我在这里看到了很多论点，您应该使其依赖于API用户，因为不得不在很多地方这样做很愚蠢：

if (isAfterSunset) light.TurnOn();
else light.TurnOff();

我不同意一些非最优发生在这里。也许看不出来，但是您的第一句话是提到“避免使用布尔参数确定行为的重要性”，这是整个问题的基础。我看不出有理由使API用户更不容易做到这一点。

我不知道您是否进行测试-在这种情况下，请考虑以下事项：

从测试的角度来看，争论甚至更加困难。想象一下编写所有测试用例以确保所有各种参数组合都能正常工作的困难。如果没有参数，这是微不足道的。