最佳实践：事件的动作枚举用法

Question

我发现自己很难为事件设计动作枚举。

f.ex制造计算处理器。

所以我应该有这样的枚举？ ：

public enum CalculatorCoreActions
{
    ProcessStarted,
    ProcessFinished,
    ProcessFailure,
    ProcessFailed,
    SubstractionStarded,
    SubstractionFinished,
    SubstractionFailure,
    SubstractionFailed,
    <etc.>...
}

或者我应该做两个枚举？，f.ex：

public enum CalculatorAction
{
    Process,
    Substraction,
    Division
}

public enum CalculationActionResult
{
   Started,
   Finished,
   Failure,
   Failed
}

甚至我应该创建一个新的类？ ：

public class CalculatorActionEventArgs : EventArgs {<...>}
public class CalculatorActionFailedEventArgs : EventArgs {<...>}
public class etc... : EventArgs {<...>}

您认为哪种方法最好？

Answer 1

你想做什么？ 您打算将枚举用于什么？ 您的第一个示例对于很少的组合可能是可以的，而第二个示例将更复杂，但更干净，更易于扩展。

我的猜测是，您希望能够显示计算状态，并可能在例如错误处理中对状态进行操作。 您可能会考虑使用State或State Machine模式而不是枚举，以避免枚举上出现大量switch语句。

Answer 2

在您提出的两个枚举选择中，我将使用第二组枚举。

为什么呢，当您将状态与行动进行交叉（字面上乘）时，您会想到一个大的增长模式。 如果您将来想添加状态或功能，则不再添加一项，而是添加1xM或Nx1项。 有关这种问题样式的其他参考，请参阅Martin Fowler的书《 重构和对象层次纠缠》。

现在，对于事件args，使用通用EventArgs并将其操作和状态赋予对象。 不要创造比您需要更多的东西，它可以最大程度地减少您制造头痛的次数。

Answer 3

这取决于您如何设计结构...对我来说，事件应该有所不同，但应该尽量不要使用更多的EventArgs，例如，像对失败的事件使用一个那样的ActionArgs等。事件参数是其唯一的数据传递机制...

现在关于枚举部分，我还无法完全掌握您的情况...。为什么要这么多的枚举？

如果您打算用它代替多个事件...如果我是您，那么我将去参加事件...但是如果您的结构需要大量事件，则说10个或更多事件来代替混合事件用枚举作为最小事件参数...说在10个事件的情况下将事件减少为3个，具有4个或5个枚举