Question

每次我写一个带有表示选项的布尔参数的方法时，我发现自己在想：“我应该用枚举来替换它，这会使读取方法调用变得更容易吗？”。

考虑以下一个对象，该对象接受一个参数，告诉实现是否应该使用其线程安全版本（我不是在这里问这样做这样做是不是很好的设计，只是使用了布尔值）：

public void CreateSomeObject(bool makeThreadSafe);
CreateSomeObject(true);

当声明在声明旁边时，参数的目的当然显而易见。当它在某些第三方库中你几乎不知道时，与以下内容相比，更难立即看到代码的作用：

public enum CreationOptions { None, MakeThreadSafe }
public void CreateSomeObject(CreationOptions options);
CreateSomeObject(CreationOptions.MakeThreadSafe);

更好地描述了意图。

当有两个表示选项的布尔参数时，事情变得更糟。查看Framework 3.5和4.0之间ObjectContext.SaveChanges(bool)发生了什么。它已经过时了，因为已经引入了第二个选项，并且整个内容已经转换为枚举。

虽然在有三个或更多元素的情况下使用枚举似乎很明显，但在这些特定情况下，您对使用枚举而不是布尔值有什么看法和经验？

Answer 1

.NET 4.0可能会有所帮助。您可以使用命名参数：

CreateSomeObject(makeThreadSafe : true);

对于旧版本，改为创建临时变量会很有用。

bool makeThreadSafe = true;
CreateSomeObject(makeThreadSafe);

Answer 2

我认为这将取决于你的方法的语义，例如你的布尔值实际上代表一个布尔值？或者仅用于标记存在而不存在其他事物？

例如：

// If true, uses 64 bit numbers, if false, 32.
doSomething(boolean)

即使你知道（至少在可预见的未来不会改变（除非你想支持16位甚至8位），如果你使用枚举，它会更容易阅读：

Options.Use32Bit,
Options.Use64Bit.

Answer 3

对我来说，这取决于几件事：

可读性
传入方法的布尔参数的数量
我可能需要的不仅仅是真/假

1）哪个更具可读性？

CreateSomeObject(CreationOptions.MakeThreadSafe);
CreateSomeObject(true);

2）现在怎么样？

CreateSomeObject(CreationOptions.MakeThreadSafe, ExtraGoodies.Include, Logging.Disable);
CreateSomeObject(true, false, false);

3）我可能需要更真实/错误/不确定的可扩展性。如果我从一开始就这样写，那么如果我只是在我的枚举中添加一个额外的项目就没有重大变化。

Answer 4

您可以在C＃4.0中使用命名参数：

CreateSomeObject(makeThreadSafe : true);

Answer 5

显然，第二种方法在没有IDE的情况下更具可读性。如果你在VS中，你可以使用intellisense来查看参数，尽管有时这可能有点笨拙。

如果您使用的是C＃4.0，则可以使用named parameters来明确您的意图。

.NET：bool vs enum作为方法参数

5 个答案: