Static Import Constant interface

Static Import https://docs.oracle.com/javase/1.5.0/docs/guide/language/static-import.html

In order to access static members, it is necessary to qualify references with the class they came from. For example, one must say:

double r = Math.cos(Math.PI * theta);

In order to get around this, people sometimes put static members into an interface and inherit from that interface. This is a bad idea. In fact, it's such a bad idea that there's a name for it: the Constant Interface Antipattern (see Effective Java Item 17). The problem is that a class's use of the static members of another class is a mere implementation detail. When a class implements an interface, it becomes part of the class's public API. Implementation details should not leak into public APIs.

The static import construct allows unqualified access to static members without inheriting from the type containing the static members. Instead, the program imports the members, either individually:

import static java.lang.Math.PI;

or en masse:

import static java.lang.Math.*;

Once the static members have been imported, they may be used without qualification:

double r = cos(PI * theta);

The static import declaration is analogous to the normal import declaration. Where the normal import declaration imports classes from packages, allowing them to be used without package qualification, the static import declaration imports static members from classes, allowing them to be used without class qualification.

So when should you use static import? Very sparingly! Only use it when you'd otherwise be tempted to declare local copies of constants, or to abuse inheritance (the Constant Interface Antipattern). In other words, use it when you require frequent access to static members from one or two classes. If you overuse the static import feature, it can make your program unreadable and unmaintainable, polluting its namespace with all the static members you import. Readers of your code (including you, a few months after you wrote it) will not know which class a static member comes from. Importing all of the static members from a class can be particularly harmful to readability; if you need only one or two members, import them individually. Used appropriately, static import can make your program more readable, by removing the boilerplate of repetition of class names.

Constant interface - Wikipedia https://en.wikipedia.org/wiki/Constant_interface

Constant interface

From Wikipedia, the free encyclopedia

 

 

Jump to navigationJump to search

In the Java programming language, the constant interface pattern describes the use of an interface solely to define constants, and having classes 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 was considered inappropriate by, e.g., Java designer Joshua Bloch.^[1] 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. It is for these reasons that implementing constants interfaces may be considered to be an anti-pattern.

Use of this pattern has a few other downsides:

1. It pollutes the class namespace 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 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).
6. Unless a developer checks any implemented interfaces when adding a constant to a class, or does so but makes a typo in the new constant's name, the value of a constant can be silently changed. Consider Example 2 below.

Note that the Java libraries use constant interface pattern themselves, proving that it may be a reasonable choice in some situations.^[2]

Contents

• 1Example 1
• 2Example 2
• 3Alternatives
• 4References

Example 1[edit]

public interface Constants {

	double PI = 3.14159;
	double PLANCK_CONSTANT = 6.62606896e-34;
}

public class Calculations implements Constants {

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

Example 2[edit]

public interface Constants {

	public static final int	CONSTANT = 1;
}

public class Class1 implements Constants {

	public static final int CONSTANT = 2;	// *

	public static void main(String args[]) throws Exception {
		System.out.println(CONSTANT);
	}
}

Before the line marked with an asterisk is added, running Class1 prints 1. After adding the line, Class1 prints 2. Both versions compile without warnings or errors.

Alternatives[edit]

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^[3] 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);
	}
}

The constants can also be imported en masse by adding a import static Constants.* statement. This achieves the same goals as using an interface, allowing the constants to be referenced without the namespace.

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 fewer 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 of the Constants class nor prevent the accidental silent modification of a constant's value, so static imports should not be considered to be a panacea.

References

1. Jump up^ Bloch, Joshua, Effective Java, 2nd Edition, p. 98
2. Jump up^ "SwingConstants"
3. Jump up^ "Static Import"