2012-02-28 94 views
2

我意識到(閱讀過SO上的其他帖子),這是壞的設計(或更好地說,在我的情況下,它也沒有意義)將狀態添加到枚舉常量。Java-Design:枚舉狀態?

然而我現在發現自己在一個情況下,我需要一些與此類似。 一個我寫的應用程序使用的錯誤常數(ENUM),我使用的指示將它們添加到一個Map<Error, ErrorInfo>(注意,這些都不是應用程序的錯誤,但是這是應用程序的一部分「錯誤」)錯誤,這些錯誤。 好吧 - 我現在意識到我實際上也需要指出INFO,WARN,FATAL的ErrorLevel。 由於錯誤的ErrorLevel取決於發生的上下文,因此我無法靜態地將ErrorLevel分配給Error-enums,換句話說,Error.E1可能是ErrorLevel.WARN一次,但可能是ErrorLevel.FATAL的另一次。

我在想我怎麼才能最好在我的設計納入本ErrorLevel,但我已經想出了到現在爲止,引入新的類,它只是包裝一個ErrorErrorLevelMap內使用而不是Error

由於錯誤和嚴重性似乎我的東西,一定是相當普遍的,我相信有這樣做更聰明的辦法,所以我會非常感謝您對如何設計這個更好的想法。

--qu

+0

難道你不能只是'ErrorErvel'添加到'ErrorInfo'?聽起來像關卡是某種信息,不是嗎? – hage 2012-02-28 07:33:20

+0

@hage好吧,事實上,這個ErrorInfo就是發生錯誤的上下文。所以它包含錯誤發生時有效的狀態信息。這就是爲什麼ErrorLevel在我看來不適合那裏的原因.. – quaylar 2012-02-28 07:55:04

回答

2

如果我理解正確的話您的問題,把過渡狀態的枚舉不會做的伎倆。由於每個枚舉類型只有一個實例通過更改錯誤級別來進行更改,因此不僅可以更改當前正在評估的錯誤,還可以更改應用程序中相同類型的所有錯誤。

你寫的ErrorLevel被要看具體情況,並在此ERRORINFO描述錯誤的次數的情況下同時進行。如果你可以根據錯誤類型和上下文來計算錯誤級別,我會建議一些靜態方法

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

這是很好,很簡單:工作和我認爲我可以適應它沒有重大變化 - 如果沒有更好的想法,這將是我的選擇:) – quaylar 2012-02-28 08:36:17

1

我不同意總額,它總是不好的設計中加入可變狀態來枚舉。枚舉類似於單例,並且只要在應用程序中使用有狀態的單例,您可以對枚舉執行相同的操作。與單身人士一樣,我們必須記住,狀態變化具有非常全面的效果。

可以肯定的,有狀態的枚舉不會在你的情況幫,因爲你想上下文中的具體錯誤的水平。

作爲替代,可以考慮使用一個簡單的多重映射:

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

的想法是存儲多個地圖不同的上下文。因此,對於已知的上下文(我很快發明了一種類型...),您可以獲得特定於上下文的參數映射。

+0

嗯,這個想法並不壞,但它需要在我的應用程序中進行重大的重構以適應...反正感謝您的輸入! – quaylar 2012-02-28 08:26:21