在方法签名中使用枚举作为逻辑？答案

【问题标题】：Use enum for logic in method signature?在方法签名中使用枚举作为逻辑？
【发布时间】：2014-06-28 15:37:59
【问题描述】：

假设我们有一个枚举（为了演示的简单示例）

public enum EnumTest{
valueA,
valueB
}

然后假设我们有一个消费者调用的方法，它将根据枚举的当前值执行某些操作。这样做有什么好处？难道是

有一个方法接收 enum ，然后根据这个 enum 的值执行操作。即

 public void DoSomething(EnumTest emumVal){
 //common code here    

switch(enumVal){

 case EnumTest.valueA: doSomething();
                       break;
 case EnumTest.valueB: doSomethingElse()
                        break;
 }
}

这似乎是我征求意见的人们最喜欢的方法，但我知道一种方法应该做一件事，而且只做一件事。让它基于一个枚举做一些稍微不同的事情让我觉得如果添加更多的枚举，这个方法可能会非常大而且笨拙

另一种选择似乎是为每个 enums.ie 提供明确的方法

public void DoSomethingForValueA(){

}

public void DoSomethingForValueB(){

}

但是一些程序员同行说这太过分了，浪费时间。

我想知道做这种事情的正确方法是什么？

【问题讨论】：

标签： c# oop enums theory

【解决方案1】：

没有。您为每个方法创建单独的类，并使用虚拟调用来选择要调用的方法。某事like this。

如果您有两种算法，它们通过相同的 API 调用，但执行的操作略有不同，那么最惯用的方法是创建定义 API 的基类或接口，然后为实现该 API 的每个算法创建一个类界面。如果您想添加新算法，这会更好，因为您不必更改包含这些方法的类，只需添加新类。从而遵循开闭原则。

【讨论】：

【解决方案2】：

他们都是正确的。如果您关心封装和 SRP，请选择第二个。

public void LogWarning() { Log(Severity.Warning); }
public void LogError() { Log(Severity.Error); }
private void Log(Severity severity) { ... };

第一个也是正确的，但是枚举可能会增长，并且您会发现自己处于根据选项调用不同方法的情况。如果你只有几个选项并且为它们执行几行代码，第一个更简洁。

还取决于您想要的 API 有多清晰。一种带参数的方法显然比 10 种名称相似但不带参数的方法更简洁。

【讨论】：