将标志传递给方法的替代方法？

Question

有时，当修复现有代码库中的缺陷时，我可能（通常出于懒惰）决定将方法从：更改

void
MyClass::foo(uint32_t aBar)
{
    // Do something with aBar...
}

为：

void
MyClass::foo(uint32_t aBar, bool aSomeCondition)
{
    if (aSomeCondition)
    {
        // Do something with aBar...
    }
}

在代码审查期间，一位同事提到更好的方法是子类 MyClass 来提供这种专门的功能。

但是，我认为只要 aSomeCondition 不违反 MyClass 的目的或内聚力，它就是可以接受的使用模式。只有当代码中渗透了标志和 if 语句时，继承才是更好的选择，否则我们可能会进入架构宇航员的领域。

这里的转折点是什么？

注意：我刚刚看到此相关答案 这表明 enum 可能是更好的选择 选择而不是 bool，但我认为我的问题在这种情况下仍然适用。

Answer 1

此类问题的解决方案不仅只有一种。

布尔的语义非常低。如果您想在将来添加新条件，则必须添加新参数...
经过四年的维护，你的方法可能有六个参数，如果这些参数都是布尔值，那么对于维护人员来说这是一个很好的陷阱。

如果情况是排他性的，Enum 是一个不错的选择。
枚举可以轻松迁移到位掩码或上下文对象。

位掩码：C++包含C语言，您可以使用一些简单的旧做法。有时，无符号整型上的位掩码是一个不错的选择（但您会失去类型检查），并且您可能会错误地传递不正确的掩码。这是从布尔值或枚举参数顺利过渡到这种模式的便捷方法。
可以通过一些努力将位掩码迁移到上下文对象。如果您必须保持构建时兼容性，您可能必须实现某种按位算术，例如 operator | 和 operator &。

如果行为分裂很大并且该行为与实例的生命周期相关，继承有时是一个不错的选择。请注意，您还必须使用多态性，如果大量使用此方法，这可能会减慢该方法的速度。
最后，继承会导致所有工厂代码发生变化...如果您有几种以排他方式进行更改的方法，您会怎么做？你会让你的特定类的代码变得混乱......
事实上，我认为这通常不是一个好主意。

方法拆分：另一种解决方案是有时将方法拆分为多个私有方法并提供两个或多个公共方法。

上下文对象：C++ 和 C 缺少命名参数，可以通过添加上下文参数来绕过。我经常使用这种模式，特别是当我必须跨复杂框架的级别传递许多数据时。

class Context{
public:
  // usually not a good idea to add public data member but to my opinion this is an exception
  bool setup:1; 
  bool foo:1;
  bool bar:1;
  ...
  Context() : setup(0), foo(0), bar(0) ... {}
};
...    

Context ctx;
ctx.setup = true; ...
MyObj.foo(ctx);

笔记：
这对于最大限度地减少静态数据的访问（或使用）或对单例对象的查询也很有用，TLS ...
上下文对象可以包含更多与算法相关的缓存数据。
...
我让你的想象力自由发挥......

反模式

我在这里添加了几个反模式（以防止签名的某些更改）：
*永远不要这样做*

• *永远不要这样做*使用静态 int/bool 进行参数传递（有些人这样做，删除这种类型是一场噩梦东西）。至少打破多线程...
• *永远不要这样做*添加一个数据成员将参数传递给方法。

Answer 2

不幸的是，我认为这个问题没有明确的答案（这是我在自己的代码中经常遇到的问题）。使用 boolean:

 foo( x, true );  

调用很难理解。

使用枚举：

 foo( x, UseHigherAccuracy );

很容易理解，但您往往会得到这样的代码：

 foo( x, something == someval ? UseHigherAccuracy : UseLowerAccuracy );

这很难说是一种改进。并且具有多个功能：

 if ( something == someval ) {
      AccurateFoo( x );
 }
 else {
      InaccurateFoo( x );
 }

您最终会得到更多的代码。但我想这是最容易阅读的，也是我倾向于使用的，但我仍然不完全喜欢它:-(

然而，我绝对不会做的一件事是子类。继承应该是 您使用过的最后一个工具。

Answer 3

主要问题是该标志是否影响类或该函数的行为。函数局部更改应该是参数，而不是子类。运行时继承应该是最后使用的工具之一。

Answer 4

我使用的一般准则是：如果aSomeCondition以主要方式改变了函数的性质，那么我考虑子类化。

与添加仅具有较小影响的标志相比，子类化是一项相对较大的工作。

一些示例：

• 如果它是一个标志，它改变了将排序的集合返回给调用者的方向，那么这就是本质上的一个微小变化（标志）。
• 如果它是一个一次性标志（影响当前调用而不是对对象的持久更改的东西），它可能不应该是一个子类（因为沿着这条轨道走下去可能会导致大量的类）。
• 如果它是一个枚举，将类的底层数据结构从数组更改为链表或平衡树，那么这是一个复杂的更改（子类）。

当然，通过完全隐藏底层数据结构可能会更好地处理最后一个，但我假设您出于性能等原因希望能够选择其中之一。

Answer 5

恕我直言，aSomeCondition 标志会更改或取决于当前实例的状态，因此，在某些条件下，此类应该更改其状态并以不同的方式处理提到的操作。在这种情况下，我可以建议使用状态模式。希望有帮助。

Answer 6

我只需将 code: 更改

void MyClass::foo(uint32_t aBar, bool aSomeCondition)
{
    if (aSomeCondition)
    {
        // Do something with aBar...
    }
}

为：

void MyClass::foo(uint32_t aBar)
{
    if (this->aSomeCondition)
    {
        // Do something with aBar...
    }
}

我总是省略 bool 作为函数参数，而更喜欢放入结构中，即使我必须调用

myClass->enableCondition();