Java-Design：枚举状态？

我意识到（阅读过SO上的其他帖子），这是坏的设计（或更好地说，在我的情况下，它也没有意义）将状态添加到枚举常量。Java-Design：枚举状态？

然而我现在发现自己在一个情况下，我需要一些与此类似。一个我写的应用程序使用的错误常数（ENUM），我使用的指示将它们添加到一个Map<Error, ErrorInfo>（注意，这些都不是应用程序的错误，但是这是应用程序的一部分“错误”）错误，这些错误。好吧 - 我现在意识到我实际上也需要指出INFO，WARN，FATAL的ErrorLevel。由于错误的ErrorLevel取决于发生的上下文，因此我无法静态地将ErrorLevel分配给Error-enums，换句话说，Error.E1可能是ErrorLevel.WARN一次，但可能是ErrorLevel.FATAL的另一次。

我在想我怎么才能最好在我的设计纳入本ErrorLevel，但我已经想出了到现在为止，引入新的类，它只是包装一个Error和ErrorLevel和Map内使用而不是Error。

由于错误和严重性似乎我的东西，一定是相当普遍的，我相信有这样做更聪明的办法，所以我会非常感谢您对如何设计这个更好的想法。

--qu

来源

2012-02-28 quaylar

难道你不能只是'ErrorErvel'添加到'ErrorInfo'？听起来像关卡是某种信息，不是吗？ – hage 2012-02-28 07:33:20

@hage好吧，事实上，这个ErrorInfo就是发生错误的上下文。所以它包含错误发生时有效的状态信息。这就是为什么ErrorLevel在我看来不适合那里的原因.. – quaylar 2012-02-28 07:55:04

如果我理解正确的话您的问题，把过渡状态的枚举不会做的伎俩。由于每个枚举类型只有一个实例通过更改错误级别来进行更改，因此不仅可以更改当前正在评估的错误，还可以更改应用程序中相同类型的所有错误。

你写的ErrorLevel被要看具体情况，并在此ERRORINFO描述错误的次数的情况下同时进行。如果你可以根据错误类型和上下文来计算错误级别，我会建议一些静态方法

public static ErrorLevel getLevel(Error, ErrorInfo) { 
    //.. 
}

来源

2012-02-28 08:14:48 Jonathan

这是很好，很简单：工作和我认为我可以适应它没有重大变化 - 如果没有更好的想法，这将是我的选择:) – quaylar 2012-02-28 08:36:17

我不同意总额，它总是不好的设计中加入可变状态来枚举。枚举类似于单例，并且只要在应用程序中使用有状态的单例，您可以对枚举执行相同的操作。与单身人士一样，我们必须记住，状态变化具有非常全面的效果。

可以肯定的，有状态的枚举不会在你的情况帮，因为你想上下文中的具体错误的水平。

作为替代，可以考虑使用一个简单的多重映射：

Map<Context, Map<Error, ErrorLevel>> errors;

的想法是存储多个地图不同的上下文。因此，对于已知的上下文（我很快发明了一种类型...），您可以获得特定于上下文的参数映射。

来源

2012-02-28 07:34:35

嗯，这个想法并不坏，但它需要在我的应用程序中进行重大的重构以适应...反正感谢您的输入！ – quaylar 2012-02-28 08:26:21

Java-Design：枚举状态？

回答

相关问题