In the Java programming language, the constant interface pattern

Design pattern (computer science)

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that...

 describes the use of an interface

Interface (Java)

An interface in the Java programming language is an abstract type that is used to specify an interface that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations...

 solely to define constants, and having classes

Class (computer science)

In object-oriented programming, a class is a construct that is used as a blueprint to create instances of itself – referred to as class instances, class objects, instance objects or simply objects. A class defines constituent members which enable these class instances to have state and behavior...

 implement that interface in order to achieve convenient syntactic access to those constants.
However, since constants are very often merely an implementation detail, and the interfaces implemented by a class are part of its exported API, this practice amounts to putting implementations details into the API, which is considered inappropriate.
In general, collecting system constants into classes independent of behaviour, might create a poor object-oriented design, because it is often a sign of low cohesion

Cohesion (computer science)

In computer programming, cohesion is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is...

. It is for these reasons that implementing constants interfaces is considered to be an anti-pattern

Anti-pattern

In software engineering, an anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.The term was coined in 1995 by Andrew Koenig,...

.

Use of this anti-pattern has a few other downsides:

1. It pollutes the class namespace
   Namespace (computer science)
   A namespace is an abstract container or environment created to hold a logical grouping of unique identifiers or symbols . An identifier defined in a namespace is associated only with that namespace. The same identifier can be independently defined in multiple namespaces...
   
    with read-only variables that may not be of use.
2. Contrary to the compile-time tactical utility of implementing a constants interface, the incidental run-time artifacts have little practical purpose (cf. marker interfaces
   Marker interface pattern
   The marker interface pattern is a design pattern in computer science, used with languages that provide run-time type information about objects...
   
    which also have no methods but are useful at run-time).
3. 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.
4. Without an IDE that resolves where the constant are coming from, tracking it back to its containing class or interface can be time consuming.
5. A variable (representing an instance) of the interface is syntactically no more useful than the interface name itself (since it has no methods).

Example

public interface Constants {

public static final double PI = 3.14159;
public static final double PLANCK_CONSTANT = 6.62606896e-34;
}
public class Calculations implements Constants {

public double getReducedPlanckConstant {
return PLANCK_CONSTANT / (2 * PI);
}
}

Alternatives

Many of the pitfalls of the anti-pattern can be avoided by converting the constants interface to a proper class with no instances:

public final class Constants {

private Constants {
// restrict instantiation
}

public static final double PI = 3.14159;
public static final double PLANCK_CONSTANT = 6.62606896e-34;
}


This still leaves the original intent of the pattern mostly un-addressed (i.e. there is no syntax for accessing the constants unqualified). However, since Java 5, consider using static import

Static import

Static import is a feature introduced in the Java programming language that allows members defined in a class as public static to be used in Java code without specifying the class in which the field is defined...

to achieve the same goal:

import static Constants.PLANCK_CONSTANT;
import static Constants.PI;

public class Calculations {

public double getReducedPlanckConstant {
return PLANCK_CONSTANT / (2 * PI);
}
}

To varying degrees, the issues listed above have now been addressed:

1. Because static members can be imported specifically, the class namespace need not be polluted with all members of the constants interface.
2. Run-time and compile-time semantics are more closely aligned when using static imports instead of constants interfaces.
3. The compiled code has one less binary compatibility constraint (that "class Calculations implements Constants").
4. Because static imports apply only to the current file (and not the whole class hierarchy) it is easier to discover where each static member is declared.
5. There is less need to declare variables of the constants interface type, and it is potentially clearer that no concrete instances actually exist.

Note however, the changes do nothing to improve the cohesion

Cohesion (computer science)

In computer programming, cohesion is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is...

of the Constants class, so static imports should not be considered to be a panacea.