枚举内部的逻辑

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;
  }
}

我个人的偏好是将其提取到服务中。将方法放在枚举中的争论主要是为了方便。这个想法是，您不必去服务来获取它，而是可以直接查询枚举。

我的论点集中在关注点分离和将任何类型的逻辑抽象为服务。我不认为“方便”是将此方法放入枚举中的有力论据。

从最佳实践的角度来看，哪一个更好？或者这仅仅是个人喜好和代码风格的问题？

Answer 1

嗯，我以前做过这件事，但这当然并不意味着这是“最好”的事情。

不过，从我的角度来看，我更愿意在枚举上使用这种逻辑，出于同样的原因，您不会将“toString”方法移出到服务中。逻辑仅涉及枚举本身及其自身的表示。

我认为将这样的方法移到服务中会产生误导 - 通过将其放在枚举上，您就可以提前了解枚举具有“toMap”方法的事实。不了解该服务并且只是查看枚举的人可能不知道这一点。

它还有助于 IDE 中的自动完成 - 我可以点击“.”键并立即查看该对象提供的方法。

Answer 2

我认为这可能取决于个人喜好以及你是否认为逻辑将来可能会改变。

枚举逻辑的最佳用例（因为它非常静态）是用于不会改变的事物。 java.util.concurrent.TimeUnit 中的逻辑就是一个很好的例子：时间单位之间的转换因子是明确定义的并且永远不会改变，因此它是静态逻辑的良好候选者嵌入枚举中。

Answer 3

我看不出有任何有说服力的理由来解释为什么做你所建议的事情是“好的做法”……或“坏的做法”……。

我倾向于以方便为理由。但坦率地说，这不是那种花很多时间争论的事情......在我看来。

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

就像任何取决于用途的事情一样，有一般规则，但实用性始终应该赢得争论。地图是用来做什么的？您是否需要限制地图的内容，例如，如果地图用于填充组合框，是否需要删除某些选项，例如，如果某些承运商仅处理某些包裹类型，则可以使用策略来填充地图，最好在枚举之外完成。

尽管如此，我更倾向于在其他地方创建地图，这种额外的间接级别永远不会妨碍灵活性，并且可以节省很多痛苦，并且现在增加很少的开销。您还可以对其进行编码，以便获得与其他枚举类似的功能。