常量的Java，接口或組合類

我有一個關於我的程序設計的問題。我有一個存儲公共常量的類A，以便我可以在另一個類中使用這些常量。常量的Java，接口或組合類

public static final String error_code1 = "Fatal Error"; 
public static final String error_code2 = "XXXX"; 
... 
...

組成與界面之間，我不知道哪一個更適合。從我的想法來看，因爲我只需要在我的程序中進行價值比較的常量，所以我認爲構圖是足夠的（低耦合）。

但是，你們可以給我一些建議/參數從軟件deign的角度來看？（內聚，耦合，維護困難等）

來源

2014-11-21 hades

這可以用Enums完全解決。 – Mirco 2014-11-21 13:17:41

你應該使用枚舉的理想，否則去一個接口。 – 2014-11-21 13:20:20

首先，我建議你在這種情況下使用枚舉。

public enum ErrorCode { 
    FATAL_ERROR("Fatal Error"), 
    X_ERROR("XXXX"); 

    public final String msg; 
    private ErrorCode(String msg) { 
     this.msg = msg; 
    } 
}

如果這個不適合你出於某種原因，我會去與私人（未使用）構造一個final實用工具類。

無論如何，由於字段是靜態的和最終的，我會而不是考慮引用A或實現A來獲取常量。

來源

2014-11-21 13:17:44 aioobe

接口不會比具有私有構造函數的最終類更好嗎？ – 2014-11-21 13:21:26

這些類型的字段是實現細節而不是類的合同。僅僅因爲它「方便」並不意味着這是個好主意。在你知道它之前，有人*實現*接口來簡化對常量的訪問。 2天后，沒有意識到這些字段是靜態的人開始傳遞ErrorConstants類型的對象。 – aioobe 2014-11-21 13:24:52

你說得對。這就說得通了。 – 2014-11-21 13:35:17

向接口添加常量被認爲是反模式，因爲接口的主要目的是定義行爲契約。使用一個枚舉或直接訪問它們，因爲它們是公共的。

來源

2014-11-21 13:22:17 grid

是的我認爲接口不應該被用於常量，因爲它失去了接口的目的 – hades 2014-11-21 13:40:12

我不會用接口來存儲常量具有靜態成員進入的接口（和實現該接口）是一個不好的做法甚至還有一個名字吧，常量接口反模式，請參閱[有效的Java] [1]，第17項：

常數接口模式是使用不好的接口。一個類內部使用一些常量是一個實現細節。實現一個常量接口會導致此實現細節泄漏到該類的導出API中。對類的用戶來說，類實現一個不變的接口並不重要。事實上，它甚至可能會混淆它們。更糟糕的是，它代表着一種承諾：如果在將來的版本中，類被修改以便它不再需要使用常量，它仍然必須實現接口以確保二進制兼容性。如果一個非終結類實現了一個常量接口，那麼它的所有子類的接口中的常量將會使其名稱空間受到污染。

我個人會去找枚舉，如果需要的話，我甚至可以用它來產生錯誤代碼或添加相關的字段/方法。

來源

2014-11-21 13:23:58 SMA

另一個類中的字符串/ int/...常量有一個問題：它們被複制到使用類的常量池中，之後沒有導入到原始類中。如果你改變一個常量的值，那麼使用類不會被強制重新編譯。

解決方案將使用一個接口，並「實現」該接口;也許醜陋。更好的是使用枚舉。

對於開放式的值域一個不會用枚舉，但面向對象的方法：

abstract class ParseError extends RuntimeException 
class ExpressionExpectedError extends ParseError 
class DigitsMayNotFollowLeadingZeroError extends ParseError 
..

在Javadoc一個可能會看到ParseError的所有子類。這裏類本身形成域值，實例化承載實際的上下文信息。這是更多的面向對象。在對象上調用幾個方法比在常量上調用多個方法要好。然而，枚舉也可以與分類方法一起使用：boolean errorHandledBySkippingToNextExpr()。

來源

2014-11-21 13:36:42

常量的Java，接口或組合類

回答

相關問題