问题
Recently I came across a piece of code wherein I found an interface with only constants. And those constants were accessed in classes using static imports. The constants were more in number (around 30 to 50).
Personally, I don't think it's a good practice. Thats why its called as Constant Interface Antipattern according to Effective Java. I don't find any good reason to go for this kind of coding.
Also, static import should be used ONLY if there are few constants to be imported by many classes in our application.
Can anyone of you please let me know if there are any other good reasons to go for constants only interface?
回答1:
Certainly prior to the introduction of enums, if you had a large collection of constants that needed to be shared between a number of classes, a Constant Interface was probably the most pragmatic way to do so.
If those constants were only used in one class then the comments in other answers ('a pattern to avoid') are quite valid - they would be most useful if declared by the class that uses them.
With newer versions of Java, I'd move towards enums with a constructor that allows value(s) to be set. However it's still the case that if the set of values are only used by a single class, it makes most sense to declare them within that class rather than separately.
回答2:
If those constants make some logical grouping, then I could use an enum instead
回答3:
I don't like this idiom at all. Why should you separate constants from the context in which they're used? I find it confusing.
This design forces a class that wants one constant to implement an entire interface that's chock full of them. And all those constants are public.
The enum idea is a good one. Anything other than this.
回答4:
A common alternative is to define public static final constants in a utility class rather than an interface. Take your constants interface, redefine it as a class, put "public static final" on each declaration, and reference these variables qualified by the classname rather than by implementing the interface.
I would tend to think of a set of constants differently to an enum.
回答5:
this link has an effective discussions covered http://www.theserverside.com/discussions/thread.tss?thread_id=19221
and the bottom line is to avoid as possible as you can using constant only interfaces
回答6:
This solutions is not great, but sometimes is the best choice to have all constants gathered in one place, for example the translation keys used in application.
Using interfaces we can create a whole storage of those and do not duplicate them.
回答7:
Not at all. I'd avoid that pattern whenever I could, not a good one at all in my book. I'd favour keeping the constants where they most make sense or where they belong from an OO perspective, and that's very rarely grouped together in an interface.
回答8:
Another alternative (besides the enum) would be a non-instatiatable class (private constructor) to gather the constants if an enum wouldn't fit (like strings, integers etc.).
Plus maybe make the class visible to the package only where it is used.
来源：https://stackoverflow.com/questions/5403392/interface-with-only-constants