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'方法移到服务中的原因相同。逻辑只涉及枚举本身及其自身的表示。

我认为将这样的方法转移到服务上会产生误导 - 通过将它放在枚举上，你可以预先知道enum有一个'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

像任何东西一样，它取决于用法，有一般规则，但实用性应该总是赢得争论。地图用的是什么？您是否需要限制地图的内容，例如如果地图用于填充组合框，是否需要删除一些选项，比如说某些运营商只处理某些包类型，可以使用策略来填充地图，这最好在枚举之外完成。

尽管如此，我的偏好是在其他地方创建地图，额外的间接水平从来不会妨碍灵活性，并且可以节省很多悲伤并且现在增加很少的开销。而且你也可以对它进行编码，这样你就可以获得与其他枚举类似的功能。

枚举中的逻辑

6 个答案: