We Keep Coding

Why to move constants to class or enum from Interface? [duplicate]

I'm looking at some open source Java projects to get into Java and notice a lot of them have some sort of 'constants' interface.
For instance, processing.org has an interface called PConstants.java, and most other core classes implement this interface. The interface is riddled with static members. Is there a reason for this approach, or is this considered bad practice? Why not use enums where it makes sense, or a static class?
I find it strange to use an interface to allow for some sort of pseudo 'global variables'.
public interface PConstants {
// LOTS OF static fields...
static public final int SHINE = 31;
// emissive (by default kept black)
static public final int ER = 32;
static public final int EG = 33;
static public final int EB = 34;
// has this vertex been lit yet
static public final int BEEN_LIT = 35;
static public final int VERTEX_FIELD_COUNT = 36;
// renderers known to processing.core
static final String P2D = "processing.core.PGraphics2D";
static final String P3D = "processing.core.PGraphics3D";
static final String JAVA2D = "processing.core.PGraphicsJava2D";
static final String OPENGL = "processing.opengl.PGraphicsOpenGL";
static final String PDF = "processing.pdf.PGraphicsPDF";
static final String DXF = "processing.dxf.RawDXF";
// platform IDs for PApplet.platform
static final int OTHER = 0;
static final int WINDOWS = 1;
static final int MACOSX = 2;
static final int LINUX = 3;
static final String[] platformNames = {
"other", "windows", "macosx", "linux"
};
// and on and on
}

It's generally considered bad practice. The problem is that the constants are part of the public "interface" (for want of a better word) of the implementing class. This means that the implementing class is publishing all of these values to external classes even when they are only required internally. The constants proliferate throughout the code. An example is the SwingConstants interface in Swing, which is implemented by dozens of classes that all "re-export" all of its constants (even the ones that they don't use) as their own.
But don't just take my word for it, Josh Bloch also says it's bad:
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 constants, 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.
An enum may be a better approach. Or you could simply put the constants as public static fields in a class that cannot be instantiated. This allows another class to access them without polluting its own API.

Instead of implementing a "constants interface", in Java 1.5+, you can use static imports to import the constants/static methods from another class/interface:
import static com.kittens.kittenpolisher.KittenConstants.*;
This avoids the ugliness of making your classes implement interfaces that have no functionality.
As for the practice of having a class just to store constants, I think it's sometimes necessary. There are certain constants that just don't have a natural place in a class, so it's better to have them in a "neutral" place.
But instead of using an interface, use a final class with a private constructor. (Making it impossible to instantiate or subclass the class, sending a strong message that it doesn't contain non-static functionality/data.)
Eg:
/** Set of constants needed for Kitten Polisher. */
public final class KittenConstants
{
private KittenConstants() {}
public static final String KITTEN_SOUND = "meow";
public static final double KITTEN_CUTENESS_FACTOR = 1;
}

I do not pretend the right to be right, but lets see this small example:
public interface CarConstants {
static final String ENGINE = "mechanical";
static final String WHEEL = "round";
// ...
}
public interface ToyotaCar extends CarConstants //, ICar, ... {
void produce();
}
public interface FordCar extends CarConstants //, ICar, ... {
void produce();
}
// and this is implementation #1
public class CamryCar implements ToyotaCar {
public void produce() {
System.out.println("the engine is " + ENGINE );
System.out.println("the wheel is " + WHEEL);
}
}
// and this is implementation #2
public class MustangCar implements FordCar {
public void produce() {
System.out.println("the engine is " + ENGINE );
System.out.println("the wheel is " + WHEEL);
}
}
ToyotaCar doesnt know anything about FordCar, and FordCar doesnt know about ToyotaCar. principle CarConstants should be changed, but...
Constants should not be changed, because the wheel is round and egine is mechanical, but...
In the future Toyota's research engineers invented electronic engine and flat wheels! Lets see our new interface
public interface InnovativeCarConstants {
static final String ENGINE = "electronic";
static final String WHEEL = "flat";
// ...
}
and now we can change our abstraction:
public interface ToyotaCar extends CarConstants
to
public interface ToyotaCar extends InnovativeCarConstants
And now if we ever need to change the core value if the ENGINE or WHEEL we can change the ToyotaCar Interface on abstraction level, dont touching implementations
Its NOT SAFE, I know,
but I still want to know that do you think about this

There is a lot of hate for this pattern in Java. However, an interface of static constants does sometimes have value. You need to basically fulfill the following conditions:
The concepts are part of the public interface of several
classes.
Their values might change in future releases.
Its critical that all implementations use the same values.
For example, suppose that you are writing an extension to a hypothetical query language. In this extension you are going to expand the language syntax with some new operations, which are supported by an index. E.g. You are going to have a R-Tree supporting geospatial queries.
So you write a public interface with the static constant:
public interface SyntaxExtensions {
// query type
String NEAR_TO_QUERY = "nearTo";
// params for query
String POINT = "coordinate";
String DISTANCE_KM = "distanceInKm";
}
Now later, a new developer thinks he needs to build a better index, so he comes and builds an R* implementation. By implementing this interface in his new tree he guarantees that the different indexes will have identical syntax in the query language. Moreover, if you later decided that "nearTo" was a confusing name, you could change it to "withinDistanceInKm", and know that the new syntax would be respected by all your index implementations.
PS: The inspiration for this example is drawn from the Neo4j spatial code.

Given the advantage of hindsight, we can see that Java is broken in many ways. One major failing of Java is the restriction of interfaces to abstract methods and static final fields. Newer, more sophisticated OO languages like Scala subsume interfaces by traits which can (and typically do) include concrete methods, which may have arity zero (constants!). For an exposition on traits as units of composable behavior, see http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf. For a short description of how traits in Scala compare with interfaces in Java, see http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-5. In the context of teaching OO design, simplistic rules like asserting that interfaces should never include static fields are silly. Many traits naturally include constants and these constants are appropriately part of the public "interface" supported by the trait. In writing Java code, there is no clean, elegant way to represent traits, but using static final fields within interfaces is often part of a good workaround.

According to JVM specification, fields and methods in a Interface can have only Public, Static, Final and Abstract. Ref from Inside Java VM
By default, all the methods in interface is abstract even tough you didn't mention it explicitly.
Interfaces are meant to give only specification. It can not contain any implementations. So To avoid implementing classes to change the specification, it is made final. Since Interface cannot be instantiated, they are made static to access the field using interface name.

I do not have enough reputation to give a comment to Pleerock, therefor do I have to create an answer. I am sorry for that, but he put some good effort in it and I would like to answer him.
Pleerock, you created the perfect example to show why those constants should be independent from interfaces and independent from inheritance. For the client of the application is it not important that there is a technical difference between those implementation of cars. They are the same for the client, just cars. So, the client wants to look at them from that perspective, which is an interface like I_Somecar. Throughout the application will the client use only one perspective and not different ones for each different car brand.
If a client wants to compare cars prior to buying he can have a method like this:
public List<Decision> compareCars(List<I_Somecar> pCars);
An interface is a contract about behaviour and shows different objects from one perspective. The way you design it, will every car brand have its own line of inheritance. Although it is in reality quite correct, because cars can be that different that it can be like comparing completely different type of objects, in the end there is choice between different cars. And that is the perspective of the interface all brands have to share. The choice of constants should not make this impossible. Please, consider the answer of Zarkonnen.

This came from a time before Java 1.5 exists and bring enums to us. Prior to that, there was no good way to define a set of constants or constrained values.
This is still used, most of the time either for backward compatibility or due to the amount of refactoring needed to get rid off, in a lot of project.

Java Interface - constants and static class in normal interface

Consider following interface.
public interface ThirdPartyApiHandler {
public OperationResult doOperation(OperationInput input);
public static class OperationResult {
//members of OpeationResult. metrics after file processing
private int successfulRecords;
private int failedRecords;
}
public static class OperationInput {
//implementations call third party API to process this file.
private String inputBatchFile;
}
//Constant which would be same across all implementations.
public static final int GLOBAL_CONSTANT = 1;
}
Is above interface a bad design?
OperationResult and OperationInput are defined as static class. They would be only used by implementations and not anywhere else. Advantage that I see here is - I don't have to create separate files for these two classes. Also they get namespace of parent class.
I have read about constant interface. But in this case, I am defining constant in normal interface which are bound to be same across all implementations and would be used in those implementations.
I am using this pattern for first time so wanted to get suggestions.

OperationResult and OperationInput are defined as static inner class.
They won't be used anywhere else.
That's OK since they will not be used anywhere else. If they're long than I would prefer to have them in separate classes.
I have read about constant interface. But in this case, I am defining constant in normal interface which are bound to be same across all implementations and would be used in those implementations.
That's a good place to declare such a field.

Having nested classes in interfaces is only matter of additional namespace. This approach help to organize the code when small interfaces are created to support simple data structure.
I recommend you this lecture: Java Tip 75: Use nested classes for better organization.
Note that public and static are redundant in this case so you do not need them. What you need to remember is that having such classes do not limit other developers to use them in other parts of code.
From my point of view, this is a good design but, i would extend and replace the class with interfaces.
public interface ThirdPartyApiHandler {
OperationResult doOperation(OperationInput input);
interface OperationResult {
int getSuccessfulRecords();
int getFailedRecords();
}
interface OperationInput {
String getInputBatchFile();
}
final int GLOBAL_CONSTANT = 1; //This could be replaced by enum but no need
}

Is above interface a bad design?
That would depend on your implementation design and it's usability in your project. Logic looks all legal to me. Possible use case of such a design can be as follows
public interface A {
static class B {
public static boolean verifyState( A a ) {
return (true if object implementing class A looks to be in a valid state)
}
}
}
Also
public static class OperationResult {
//members of OpeationResult. metrics after file processing
private int successfulRecords;
private int failedRecords;
}
In above class you have instance variables successfulRecords and failedRecords . why not make the instance variable of these static classes also static so that you can access them using ThirdPartyApiHandler.OperationResult.successfulRecords. You can even have static getters and setters for your variables.
OperationResult and OperationInput are defined as static inner class.
Contrarily to popular belief there's no such thing as an "static inner class": this simply makes no sense, there's nothing "inner" and no "outter" class when a nested class is static, so it cannot be "static inner".
Picked up above from this SO question. Read the 1st answer. I think that will answer all your questions.

Is above interface a bad design?
Quite simply, yes.
Putting any logic in an interface is semantically incorrect. An interface exposes functionality to consumers - that is its single purpose, and that should not be diluted.
Consider implementing any common functionality in a base implementation class and use inheritance, or in one or more services and use composition, in your different interface implementations.
EDIT - quote from Joshua Bloch's Effective Java
When a class implements an interface, the interface serves as a type that can be used to refer to instances of the class. That a class implements an interface should therefore say something about what a client can do with instances of the class. It is inappropriate to define an interface for any other purpose.

Public static final declaration of an instance variables in JAVA Interfaces

Why we use public static final declaration of instance variables in a Java Interface?
All the variables are implicitly public static final in a Java Interface.
Is it a good coding practice to use public static final in constant variable although it is declared inside an Interface.
For example :
public interface TestInterface{
public static final String EX_CONSTANT = "ABC";
public static final int EX_INT_CONSTANT = 5;
public static final double EX_DOUBLE = 5.0;
public static final Integer EX_INTEGER = 10;
}

Use of uniform syntax in both classes and interfaces simplifies refactoring.
You may want to turn your interface into a class somewhere in future, or move these fields into a class, and you'll get a semantical difference if you overlook some fields defined without public static final (of course, we have tools for refactoring, but nonetheless).
I think it's the same thing as support of #Overriden annotation for implementations of methods declared in interfaces that was introduced in Java 6 - it's redundant in its current form, but may become useful in case of refactoring.

I don't think so. All interface variables are implicitly public static final so no meaning to mark them same.

From the book Effective java by JOshua Bloch
Item 19: Use interfaces only to define types
When a class implements an interface, the interface serves as a type that can
be used to refer to instances of the class. That a class implements an interface
should therefore say something about what a client can do with instances of the
class. It is inappropriate to define an interface for any other purpose.
One kind of interface that fails this test is the so-called constant interface.
Such an interface contains no methods; it consists solely of static final fields, each
exporting a constant. Classes using these constants implement the interface to
avoid the need to qualify constant names with a class name. Here is an example:
// Constant interface antipattern - do not use!
public interface PhysicalConstants {
// Avogadro's number (1/mol)
static final double AVOGADROS_NUMBER = 6.02214199e23;
// Boltzmann constant (J/K)
static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
// Mass of the electron (kg)
static final double ELECTRON_MASS = 9.10938188e-31;
}
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 constants,
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.
There are several constant interfaces in the Java platform libraries, such as
java.io.ObjectStreamConstants. These interfaces should be regarded as
anomalies and should not be emulated.
If you want to export constants, there are several reasonable choices. If the
constants are strongly tied to an existing class or interface, you should add them to
the class or interface. For example, all of the boxed numerical primitive classes,
such as Integer and Double, export MIN_VALUE and MAX_VALUE constants. If the
constants are best viewed as members of an enumerated type, you should export
them with an enum type (Item 30). Otherwise, you should export the constants
with a noninstantiable utility class (Item 4). Here is a utility class version of the
PhysicalConstants example above:
// Constant utility class
package com.effectivejava.science;
public class PhysicalConstants {
private PhysicalConstants() {
} // Prevents instantiation
public static final double AVOGADROS_NUMBER = 6.02214199e23;
public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
public static final double ELECTRON_MASS = 9.10938188e-31;
}
Normally a utility class requires clients to qualify constant names with a class
name, for example, PhysicalConstants.AVOGADROS_NUMBER. If you make heavy
use of the constants exported by a utility class, you can avoid the need for qualifying
the constants with the class name by making use of the static import facility,
introduced in release 1.5:
// Use of static import to avoid qualifying constants
import static com.effectivejava.science.PhysicalConstants.*;
public class Test {
double atoms(double mols) {
return AVOGADROS_NUMBER * mols;
}
...
// Many more uses of PhysicalConstants justify static import
}
In summary, interfaces should be used only to define types. They should not
be used to export constants.

IMO, Interface is a contract. Once variables are declared or defined they are not going to change. That's why generally we make them public static final.
Readability is another factor which makes declaration redundant.

Admittedly, it's redundant. Usually people just don't know that they're implicitly public static final and declare it anyway. Ditto with things like declaring:
public abstract interface Test { // Interfaces are always abstract
public void testMethod(); // Interface methods are always public
abstract void anotherTestMethod(); // Also redundant
}
Usually it just boils down to the fact that people don't know that they don't have to declare it one way or the other. I once talked to someone (who was a seasoned programmer) that thought the default case in switch is required or it won't compile.
That being said, the only argument to be made for adding them is that they clarify what their actual visibility and whatnot actually is. It's a matter of readability and clarification, and whether or note to include them is irrelevant in terms of how it actually behaves.

When you are working in a team of programmers, you will find junior programmers who do not know the fact that by default the variables are public static final in the interface, and seeing the variables declared that way will give them extra information about the interface and the use of its variables.

You are correct: it is redundant. I don't like to add redundant syntax at any time. However the practice does has its adherents. Some also like to add parentheses around return-expressions, on the fallacious grounds that it's like an 'if' statement; extra parentheses to 'clarify' arithmetic expressions that a third-grader would understand; etc. It's all part of the rich tapestry of life.

Header like Class for defining constants in Java [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How do you define a class of constants in Java?
I would like to define a class in my package to contain only the constant vales like defines in C. I am a C programmer learning Java so perhaps that is why I still want to have some header like class :)
For this purpose here is the class I have:
package com.myclasses
public class defines{
public static byte final ID_1= 0x01;
public static final ID_2= 0x02;
public static String company_name="XYZ";
}
Then somewhere in a another class in the same package, I use these defines as follows:
byte idval = defines.ID_1;
... and so on.
My question is for such a "header" class what is the best way of defining it?
It has only static variables so should I define the class also static?
What about the access modifier? Since it has defines in it I thought it could be made "public".
Please advise.

Don't
There are hardly any constants that have value in their own. They only make sense in context. That context is a real class, i.e. a class that has instances (at least one). Declare the constants in that class.
As for the modifiers: reduce the scope as far as possible: Private if only used inside the class where they are declared, public if anybody using the class needs the constants as well.
If you declare more then one constant of same type in one class, think about if a enum makes mores sense.
And yes, constants should be static.

This pattern is called the "constant class" pattern (I think).
One way of using it is to make it an interface and implement it, then you get the references for "free":
public interface Defines {
static byte final ID_1= 0x01;
static final ID_2= 0x02;
// etc
}
public class MyClass implements Defines {
byte idval = ID_1; // Note: No need to refer to the class "Defines" here
}
but most people consider this an anti-pattern, because it isn't a real interface (it has no methods). Nevertheless, it is kind of cool, and may be a good way for you to ease into java.
The "standard" approach is to define a "utility class", which is one that has only static fields and methods, give it a private constructor to reinforce that you shouldn't create one of these. This is what you have done - keep doing it.
If you have a few constants that are different values of "the same thing", eg directions on a compass, etc, strongly consider using an enum. You should read up on them.

Use a final class
eg : public final class defines {
// private constructor
private defines() {
}
}
The constants should be defined as
public static final <type> constantName = <value>;
Wouldn't recommend enums in this scenario as Enums should be used when we are having constants which are having some relation between them.
Having a utility class like this, is the approach we use in our project to define constants that needs to be accessed across a project.
If you needs the constants only in that certain class then defining them in the class itself will be the best solution. eg:
private static final <type> constantName = <value>;

Just use an Interface in Java to define all your Constants..
public interface Const {
String GOVERNMENT = "Government";
String PUBLIC = "Public";
...
}
You can use class also.

Are interfaces a valid substitute for utility classes in Java 8? [duplicate]

This question already has answers here:
Java 8: Interface with static methods instead of static util class
(5 answers)
Closed 7 years ago.
For the past decade or so, I've been using the pattern below for my Java utility classes. The class contains only static methods and fields, is declared final so it can't be extended, and has a private constructor so it can't be instantiated.
public final class SomeUtilityClass {
public static final String SOME_CONSTANT = "Some constant";
private SomeUtilityClass() {}
public static Object someUtilityMethod(Object someParameter) {
/* ... */
return null;
}
}
Now, with the introduction of static methods in interfaces in Java 8, I lately find myself using a utility interface pattern:
public interface SomeUtilityInterface {
String SOME_CONSTANT = "Some constant";
static Object someUtilityMethod(Object someParameter) {
/* ... */
return null;
}
}
This allows me to get rid of the constructor, and a lot of keywords (public, static, final) that are implicit in interfaces.
Are there any downsides to this approach? Are there any benefits to using a utility class over a utility interface?

You should use interface only if you expect that somebody would implement it. For example, java.util.stream.Stream interface has a bunch of static methods which could be located in some Streams or StreamUtils class prior to Java 8. However it's a valid interface which has non-static methods as well and can be implemented. The java.util.Comparable is another example: all static methods there just support the interface. You cannot forbid users from implementing your public interface, but for utility class you can forbid them to instantiate it. Thus for the code clarity I suggest not to use interfaces unless they are intended to be implemented.
A note regarding #saka1029 answer. While it's true that you cannot define helper private methods and constants in the same interface, it's not a problem to create a package-private class in the same package like MyInterfaceHelper which will have all the necessary implementation-related stuff. In general package-private classes are good to hide your implementation details from the outer world.

Going based on the person who coined the Constant Interface pattern an anti-pattern, I would say although you don't intend the client(s) to implement the interface, it's still possible, possibly easier, and shouldn't be allowed:
APIs should be easy to use and hard to misuse. It should be easy to do simple things; possible to do complex things; and impossible, or at least difficult, to do wrong things.
Although as mentioned below, it really depends on the target audience
A lot of easy-to-use designs patterns get a lot of criticism (Context pattern, Singleton pattern, Constant Interface pattern). Heck, even design principles such as the law of demeter gets criticised for being too verbose.
I'd hate to say it, but these kinds of decisions are opinion based. Although the context pattern is seen as an anti-pattern, it's apparent in mainstream frameworks such as Spring and the Android SDK. It boils down to the environment, as well as target audience.
The main downside that I can find is listed as the third listing under "downsides" in the Constant Interface wiki:
If binary code compatibility is required in future releases, the constants interface must remain forever an interface (it cannot be converted into a class), even though it has not been used as an interface in the conventional sense.
If you ever figure "Hey, this actually isn't a contract and I want to enforce stronger design", you will not be able to change it. But as I've said, it's up to you; maybe you won't care to change it in the future.
On top of that, code clarity as mentioned by #TagirValeev. Interfaces have the intent of being implemented; if you don't want someone to implement the API you're supplying, don't make it implementable. But I believe this revolves around the "target audience" statement. Not gonna lie, I'm with you on the less-verbose foundation, but it depends on who my code is for; wouldn't wanna use a constant interface for code that may get reviewed.

You should not use interface.
Interfaces cannot have private constants and static initializers.
public class Utility {
private Utility() {}
public static final Map<String, Integer> MAP_CONSTANT;
static {
Map<String, Integer> map = new HashMap<>();
map.put("zero", 0);
map.put("one", 1);
map.put("three", 3);
MAP_CONSTANT = Collections.unmodifiableMap(map);
}
private static String PRIVATE_CONSTANT = "Hello, ";
public static String hello(String name) {
return PRIVATE_CONSTANT + name;
}
｝

I think it would work. I think the variable SOME_CONSTANT defaults to being static final in your SomeUtilityInterface, even though you didn't explicitly say so. So, it would work as a Utility but wouldn't you have some mutability problems that you wouldn't have with a regular class with all member variables being required to be final? As long as thats not an issue with your particular implementation of the default methods, I can't think of a problem.