Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from codereview.stackexchange.com Nov 8 '12 at 15:34

This question came from our site for peer programmer code reviews.

    
you might look into this stackoverflow.com/questions/2659593/… –  paritosh Nov 8 '12 at 11:34
    
yes i looked there and i also added a comment/ question. so you can take a look there also? –  Łukasz Rzeszotarski Nov 8 '12 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. –  E-Man Nov 8 '12 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 –  Łukasz Rzeszotarski Nov 8 '12 at 14:26
    
I'll add an answer, thanks for the clarification! –  E-Man Nov 8 '12 at 14:39
add comment

2 Answers

up vote 8 down vote accepted

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.

share|improve this answer
    
I wouldn't bother with the private constructor. Since there's no reason anyone would ever instantiate the class, why prevent it? –  kevin cline Nov 8 '12 at 16:15
2  
@kevincline to make it clear to any other programmer that there are no instances where you would (or could) instantiate the class. –  MichaelT Nov 8 '12 at 19:34
    
@MichaelT: Isn't that already obvious from the class name, and the fact that all the members and methods are static? –  kevin cline Nov 8 '12 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. –  E-Man Nov 8 '12 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. –  kevin cline Nov 13 '12 at 18:01
show 1 more comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.