枚舉中的邏輯

Question

我和我的同事正在討論枚舉中的邏輯。 我個人的偏好是在Java枚舉中沒有任何邏輯（盡管Java提供了這樣做的能力）。 這個問題的討論集中在枚舉內部有一個方便的方法返回一個地圖：

public enum PackageType {
  Letter("01", "Letter"),
  ..
  ..
  Tube("02", "Packaging Tube");

  private String packageCode;
  private String packageDescription;

  ..
  ..

  public static Map<String, String> toMap() {
     Map<String, String> map = new LinkedHashMap<String, String>();
     for(PackageType packageType : PackageType.values()) {
         map.put(packageType.getPackageCode(), packageType.getPackageDescription());
     }
     return map;
  }
}

我個人的偏好是將其推廣到服務中。 在enum中使用方法的論據集中在便利性上。 這個想法是你不必去服務獲得它，但可以直接查詢枚舉。

我的論點集中在關注的分離和將任何類型的邏輯抽象為服務。 我不認為“方便”是將這種方法置於枚舉中的有力論據。

從最佳實踐的角度來看，哪一個更好？ 或者它只是歸結為個人偏好和代碼風格？

Answer 1

好吧，我以前做過這個，但這並不意味着它是'最好'的事情。

但是，從我的角度來看，我寧願在枚舉上使用那個邏輯，因為你不會將'toString'方法移到服務上。 邏輯只涉及枚舉本身及其自身的表示。

我認為將這樣的方法轉移到服務上會產生誤導 - 通過將它放在枚舉上，你可以預先知道枚舉有一個'toMap'方法。 一個不了解服務但只是看着枚舉的人可能不知道。

它還有助於在IDE中自動完成 - 我可以點擊'。' 鍵並立即查看對象提供的方法。

Answer 2

我認為這可能取決於個人偏好以及您是否認為未來的邏輯可能會發生變化。

枚舉邏輯的最佳用例（因為它非常靜態）適用於不會改變的事物。 java.util.concurrent.TimeUnit的邏輯就是一個非常好的例子：時間單位之間的轉換因子是明確定義的，不會改變，因此它是嵌入在枚舉中的靜態邏輯的良好候選者。

Answer 3

我看不出任何有說服力的理由為什么它是“良好實踐”......或“不良實踐”......做你所建議的。

我傾向於尋求方便論證。 但坦率地說， 這不是那種花費人工日辯論的東西 ...... IMO。

Answer 4

我已經在枚舉中嘗試了幾次邏輯，但我唯一真正高興的是：

// not compiled, so might have errors...
public enum Foo
{
   A,
   B;

   // not complete, doesn't properly handle invalid cases...
   public static Foo fromString(final String str)
   {
       final String strLower;
       final Foo    val;

       strLower = str.toLowerCase();

       if(strLower.equals("a")
       {
           val = A;
       }
       else if(strLower.equals("b")
       {
           val = B;
       }
       else
       {
           throw new IllegalArgumentException(/*...*/);
       }

       return (val);
   }
}

通常，一旦開始添加實例變量/方法，您可能應該使用適當的類做一些事情。

Answer 5

我首先把它放在枚舉中。 如果系統中只有一個toMap（）方法，那么額外的類肯定是​​不必要的並且會很煩人。

如果我有一堆枚舉，我想從中創建這樣的地圖，或者可能預料到這種情況，那么我將創建一個靜態實用程序類，以及一個通用的實用方法來實現這一點。

我個人的觀點是，實用性陷阱理論。

編輯：哦等等，這將很難提供一個通用的實用工具方法..在這種情況下，如果該方法將是特定的枚舉，我肯定會把它放在枚舉。 如果我是維護程序員，如果你需要額外的課程，我會非常不滿意。

Answer 6

像任何東西一樣，它取決於用法，有一般規則，但實用性應該總是贏得爭論。 地圖用的是什么？ 你是否需要限制地圖的內容，例如，如果地圖用於填充組合框，是否需要刪除一些選擇，比如說某些運營商只處理某些包類型，可以使用策略來填充一張地圖，最好在枚舉之外完成。

盡管如此，我的偏好是在其他地方創建地圖，額外的間接水平從來不會妨礙靈活性，並且可以節省很多悲傷並且現在增加很少的開銷。 您還可以對其進行編碼，以便您可以獲得與其他枚舉類似的功能。