Take the 2-minute tour ×

In his book Effective Java, Joshua Bloch recommends against using Interfaces to hold constants,

The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class’s exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the con-stants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.

His reasoning makes sense to me and it seems to be the prevailing logic whenever the question is brought up but it overlooks storing constants in interfaces and then NOT implementing them.

For instance,

public interface SomeInterface {
    public static final String FOO = "example";

public class SomeOtherClass {
    //notice that this class does not implement anything
    public void foo() {
        thisIsJustAnExample("Designed to be short", SomeInteface.FOO);

I work with someone who uses this method all the time. I tend to use class with private constructors to hold my constants, but I've started using interfaces in this manner to keep our code a consistent style. Are there any reasons to not use interfaces in the way I've outlined above?

Essentially it's a short hand that prevents you from having to make a class private, since an interface can not be initialized.

share|improve this question
You have more than ten questions you haven't accepted. ;) –  Peter Lawrey Jun 10 '11 at 15:36
Is it out of the question to simply refactor away the constant interface classes? Move the constants to the classes that use them; move common ones into enums. –  Rob Hruska Jun 10 '11 at 15:38
@Peter Lawery, I can defend the majority of them. Sometimes I ask a question and get moved on to something different before I can try any solutions, which sucks for the answerer to be sure, but I upvote but don't mark any thing as the answer I haven't personally tested. Sometimes I just don't get any helpful answers and don't have time to come back and write up the solutions so the question stays open. When I get some free time I'll have to try and do some bookkeeping, just haven't had the time or the inclination lately however. –  James McMahon Jun 10 '11 at 15:45
Not sure you are going to impress the people who answered your questions with your defence. ;) People should feel you will ask questions which can be reasonably answered and you will follow up on their contribution. –  Peter Lawrey Jun 10 '11 at 15:51
This is a best practice question and as such doesn't have a concrete answer. I'm marking one that agree with most for now, but there are a lot of other good points raised by other answers. –  James McMahon Jun 10 '11 at 16:54

4 Answers 4

up vote 3 down vote accepted

I don't think a class with a private constructor is any better than using an interface.

What the quote says is that using implements ConstantInterface is not best pratice because this interface becomes part of the API.

However, you can use static import or qualified names like SomeInteface.FOO of the values from the interface instead to avoid this issue.

share|improve this answer
I disagree with you. It still becomes part of the API. I can still implement SomeInterface. I can still write public methods that accept SomeInterface as an argument. Do we just trust everyone to hold up the agreement that no one implements SomeInterface? This just begs for developers to shortcut and reduce code quality. At least class with a no-args constructor is slightly more clear as to what its intention is. Its a class with no behavior just data. Interfaces can't communicate this because they have no behavior to begin with. Its not clear that the interface is just a constant bucket. –  nsfyn55 Jun 10 '11 at 19:59
You have to think about what are the key issues for your users and the system you have and how do you prevent them. If this is one of the most serious issues your application has, use a code analysis tool to find where this happens, because you are very lucky to be working on such a system. ;) Very few users which even understand this issue never mind raise it as a problem. –  Peter Lawrey Jun 11 '11 at 7:49
Users aren't the point. We are talking about code quality. There are plenty of non-scalable, hacked together, monstrosities that users are more than happy with(Windows?). Its our job as developers to care about the internals and to look at deeper issues than just the user experience. The user doesn't care about this issue, but he does care when he gets a "Error:Contact System Administrator dialog" directly related to a sloppy, soupy API. Think about it man the user doesn't care if we have meaningful logging or fail fast scenarios to prevent corruption. That doesn't mean we don't do them –  nsfyn55 Jun 12 '11 at 23:27
There are plenty of code analysis tools to help discourage you from inheriting an interface like ConstantsInterface There is a lot you worry about in your program and if you are worrying about all the little details which might theoretically cause a problem for the user, you will miss an important detail which will cause a program. –  Peter Lawrey Jun 13 '11 at 5:48
Its about writing good, tight code man. Garbage in/ Garbage Out software that uses these dated, ill-advised practices will always be more prone to problems. We all acknowledge there are problems with using an interface so a better question would be what are the advantages to using a constants interface that make it so appealing? If there are none then why do it when you get the some result for with some added risk for your troubles? –  nsfyn55 Jun 13 '11 at 15:21

I guess it does the job, but as a friend once said: "You can try mopping a floor with an octopus; it might get the job done, but it's not the right tool".

Interfaces exist to specify contracts, which are then implemented by classes. When I see an interface, I assume that there are some classes out there that implement it. So I'd lean towards saying that this is an example of abusing interfaces rather than using them, simply because I don't think that's the way interfaces were meant to be used.

I guess I don't understand why these values are public in the first place if they're simply going to be used privately in a class. Why not just move them into the class? Now if these values are going to be used by a bunch of classes, then why not create an enum? Another pattern that I've seen is a class that just holds public constants. This is similar to the pattern you've described. However, the class can be made final so that it cannot be extended; there is nothing that stops a developer from implementing your interface. In these situations, I just tend to use enum.


This was going to be a response to a comment, but then it got long. Creating an interface to hold just one value is even more wasteful! :) You should use a private constant for that. While putting unrelated values into a single enum is bad, you could group them into separate enums, or simply use private constants for the class.

Also, if it appears that all these classes are sharing these unrelated constants (but which make sense in the context of the class), why not create an abstract class where you define these constants as protected? All you have to do then is extend this class and your derived classes will have access to the constants.

share|improve this answer
"I don't understand why these values are public in the first place if they're simply going to be used privately in a class". I just did that to create a terse example. –  James McMahon Jun 10 '11 at 15:42
@James Ah, a contrived example - got it :) –  Vivin Paliath Jun 10 '11 at 15:43
Enums make sense for me when the values are connected, but creating an Enum to store one value seems wasteful and putting unrelated Enum seems like a misuse of Enums. –  James McMahon Jun 10 '11 at 17:38
@James McMahon Then creating an interface to hold just one value is even more wasteful! :) You should use a private constant for that. While putting unrelated values into a single enum is bad, you could group them into separate enums, or simply use private constants for the class. –  Vivin Paliath Jun 10 '11 at 18:14

Constants are a bad thing anyway. Stuffing a bunch of strings in a single location is a sign that your application has design problems from the get go. Its not object oriented and (especially for String Constants) can lead to the development of fragile API's

If a class needs some static values then they should be local to that class. If more classes need access to those values they should be promoted to an enumeration and modeled as such. If you really insist on having a class full of constants then you create a final class with a private no args constructor. With this approach you can at least ensure that the buck stops there. There are no instantiations allowed and you can only access state in a static manner.

This particular anti-pattern has one serious problem. There is no mechanism to stop someone from using your class that implements this rouge constants interface.Its really about addressing a limitation of java that allows you to do non-sensical things.

The net out is that it reduces the meaningfulness of the application's design because the grasp on the principles of the language aren't there. When I inherit code with constants interfaces, I immediately second guess everything because who knows what other interesting hacks I'll find.

share|improve this answer
I mostly agree with you but you've asserted that a bunch of thing are bad without really explaining why. Also, you'd need a private constructor in a class for constants to prevent the default no-arg constructor from taking effect. –  Brad Mace Jun 10 '11 at 16:04
@bernance - thats what I meant about the constructor. Thanks for your feedback –  nsfyn55 Jun 10 '11 at 19:23
@bernance - Its a difficult topic to articulate. Because the reality is that it probably won't ever cause severe problems in anyone's code, given that there are still better ways to approach handling values that will never change. I think "Mopping the floor with the octopus" is definitely the closest anyone has ever come to putting y thoughts into words. –  nsfyn55 Jun 10 '11 at 19:29

Creating a separate class for constants seems silly. It's more work than making an enum, and the only reason would be to do it would be to keep unrelated constants all in one place just because presumably they all happen to be referenced by the same chunks of code. Hopefully your Bad Smell alarm goes of when you think about slapping a bunch of unrelated stuff together and calling it a class.

As for interfaces, as long as you're not implementing the interface it's not the end of the world (and the JDK has a number of classes implementing SwingConstants for example), but there may be better ways depending on what exactly you're doing.

  • You can use enums to group related constants together, and even add methods to them
  • you can use Resource Bundles for UI text
  • use a Map<String,String> passed through Collections.unmodifiableMap for more general needs
  • you could also read constants from a file using java.util.Properties and wrap or subclass it to prevent changes

Also, with static imports there's no reason for lazy people to implement an interface to get its constants when you can be lazy by doing import static SomeInterface.*; instead.

share|improve this answer

Your Answer


