Java Enum 属性最佳实践答案

【问题标题】：Java Enum property best practiceJava Enum 属性最佳实践
【发布时间】：2011-05-12 20:03:26
【问题描述】：

我见过两种处理带有属性的枚举的方法。一个比另一个好？

作为属性：

public enum SEARCH_ENGINE {
    GOOGLE("http://www.google.com"),
    BING("http://www.bing.com");

    private final String url;

    private SEARCH_ENGINE(String url) {
        this.url = url;
    }

    public String getURL() {
        return url;
    }
}

作为一种方法：

public enum SEARCH_ENGINE {
    GOOGLE {
        public String getURL() {return "http://www.google.com";}
    },
    BING {
        public String getURL() {return "http://www.bing.com";}
    };

    public abstract String getURL();
}

【问题讨论】：

第二个变种真的可以编译吗？它似乎为每个枚举常量创建单独的类（这是您可以覆盖 getURL() 的唯一方法。第一个肯定更好。
就个人而言，我更喜欢第二个。它更灵活。但本质上他们在做同样的事情。
@mellamokb - 行为可能相同。它如何被翻译成字节码和执行是非常不同的（是的，回答我之前的问题，它确实编译，它确实创建了匿名子类）
我总是使用第一个。我从来没有使用第二种方法来创建枚举。
@JustinKSU：嗯，这意味着 JIT 不太可能内联它。不过，我认为它变得重要的可能性几乎为零。

标签： java enums enumeration

【解决方案1】：

第一个对我来说显然看起来更干净 - 它利用了枚举的每个元素都有一个在初始化时已知的固定字符串 URL 的共性。您在第二个版本的每个实现中有效地重复了该“逻辑”。在每种情况下，您都在重写一个提供相同 logic 的方法（“只返回一个在编译时已知的字符串”）。我更喜欢为行为的变化保留覆盖。

我建议首先将 url 字段设为私有。

【讨论】：

我同意。当我没有任何逻辑时，我通常使用 case 1，只有常量，而当我有逻辑时，我使用 case 2。
1. url 是私有的... 2. 我看到的这种方法的缺点是当有多个属性时。很高兴看到关联的属性旁边的值，而不必检查构造函数。
@JustinKSU：是的，它是私有的，当然应该是 - 但 IMO 它应该也是最终的。

【解决方案2】：

看看Josh Bloch's Effective Java这一章的第21条。它谈到了类型安全的枚举模式。

【讨论】：

本章似乎是关于如何用JDK 1.5之前的类实现枚举

【解决方案3】：

我会选择第一个，因为如果您不知何故忘记添加 url，编译器会抱怨。第二个会让你在这里犯错误。

【讨论】：

在第二种方法中，如果您不覆盖实现相同目的的 getURL() 方法，编译器会报错。
编译器也会在第二次抱怨：<anonymous SEARCH_ENGINE$2> is not abstract and does not override abstract method getURL() in SEARCH_ENGINE。