5

Some time ago I have read two different books and each of them gives totally different answer for the question if it is a good pattern to define constant values in the interface (in java).

So I am curious of your opinions with some reasonable arguments.

Is it a good habit/ pattern to define constant values in interfaces in java?

Is it generally good, generally bad or it depends?

Improve this question
4
  • you might look into this stackoverflow.com/questions/2659593/… Commented Nov 8, 2012 at 11:34
  • yes i looked there and i also added a comment/ question. so you can take a look there also? Commented Nov 8, 2012 at 11:45
  • 1
    If all those classes use some similar constants and methods, why not extend an abstract class instead? If not, Effective Java puts a strong case in for Enums. Commented Nov 8, 2012 at 14:03
  • @E-Man assume that we have A (extends) B, C (extends) D, B and D are from external library (I cannot create common super class for them). So because that we don't have multiple inheritance it is not possible to make an abstract super class for them. In this case the intention is not to create the interface as a place for storing constant values (what I also consider as antipattern), but the interface is rather something which gives some common behaviour and features (constant values) for my classes A and C Commented Nov 8, 2012 at 14:26

2 Answers 2

Reset to default
10

Item 19 of Effective Java 2nd ed. recommends the following:

If the constants are strongly tied to an existing class or interface, you should add them to the class or interface...If the constants are best viewed as members of an enumerated type, you should export them with an enum type. Otherwise, you should export the constants with a noninstantiable utility class.

public class SomeConstants { private SomeConstants() { } // Private default constructor public static final double WEIRD_NUMBER = 123456.7; public static final int ANOTHER_NUMBER = 5; }

Edit: As with all things, exceptions exist. This case (constants and some methods need to be shared by external types) might be a good argument for using an interface in this manner.

Improve this answer
6
  • I wouldn't bother with the private constructor. Since there's no reason anyone would ever instantiate the class, why prevent it? Commented Nov 8, 2012 at 16:15
  • 3
    @kevincline to make it clear to any other programmer that there are no instances where you would (or could) instantiate the class. Commented Nov 8, 2012 at 19:34
  • @MichaelT: Isn't that already obvious from the class name, and the fact that all the members and methods are static? Commented Nov 8, 2012 at 20:44
  • If a public constructor isn't part of the API, then I don't see a real downside to enforcing that by using a private one. Commented Nov 8, 2012 at 21:11
  • @E-Man: the downside is more noise in the code to defend against a non-problem. If your team is likely to instantiate SomeConstants, then you will have much bigger problems that no amount of defensive coding can prevent. Commented Nov 13, 2012 at 18:01
1

I use constants in interface to have the same references when my programms have internal parameters, about all when thoses constants may change in next version,
and I use enum otherwhere.

I have also a interface of usual constant by default, those constants are use if no other environment parameter given by some myFile.properties overwrite them.

Effective Java (2008) from Joshua Bloch give many tips about it.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.