Java interface constant anti-pattern and definition of Java constants

Java beginners inadvertently define constants in interfaces. The only reason is that interfaces cannot be instantiated, and constants defined in interfaces do not need to be attached to instances. This is mainly because JDK itself has set many such examples, such as java. io. ObjectStreamConstans, mostly before the arrival of the Enum type.

In fact, Java interface constants are an anti-pattern for the following reasons:

1. an interface cannot be implemented or inherited. That is to say, the sub-interface or the implementation can overwrite the definition of a constant (with the same name), so that through the parent, sub-interface (or implementation) constants to be referenced may be inconsistent.
2. similarly, due to implementation or inheritance, a large number of interfaces, classes, or instances can be used to reference the same constant in the inheritance tree, as a result, the constants defined in the interface pollute the namespace. (The Java Compiler allows an instance to reference class variables)
3. The interface implies that it needs to be implemented and represents a type. Its public member is the API to be exposed. The constant defined in the interface cannot be called an API.

4. This is a bit repetitive. Java allows sub-classes to reference constants defined in the parent class, and each level references the constants of the parent class for the like instance, which can cause quite confusion. The defined constants cannot guarantee a single reference method.

For details, see Article 4 of objective java: interfaces are only used to define types.

Since the interface is not suitable for defining constants, where should it be a constant? The interface is generated for implementation/Inheritance. If it is placed in the class and the class is final, it is enough to close the constructor. So our previous interface constant definition

Public interface Gender {public static final int MALE = 1; public static final int FEMALE = 0;} is changed to public final class Gender {private Gender () {} public static final int MALE = 1; public static final int FEMALE = 0 ;}

This is the method of writing JDK java. nio. charset. StandardCharsets.

Defining constants in a closed final class is indeed a big step forward. But there is a fatal flaw in defining variables like above. If a method wants to receive MALE or FEMALE from Gender, the type is int, but you can actually input a 3, so this method may be dumb. That is to say, there is no boundary limit for defining constants in this way.

If you want to define some loose constant values, you can use final closed classes, such

Public final class ConfigConstants {private ConfigConstants () {} public static final String FILE_PATH = "/data/credentials. conf "; public static final int MAX_LIMIT = 100;} if multiple constant values to be defined are homogeneous, so the best way to define constants should be enumeration (in the above example, there is no reason to use enumeration) public enum Gender {MALE, FEMALE}

In essence, the above definition inherits java. lang. the final class of Enum obtains java. lang. enum is a useful method and is directly forbidden by the compiler to be instantiated. It has two limited Gender members: MALE and FEMALE. For Java enumeration principles, see: understanding Java enumeration by decompiling bytecode.

The Gender enumeration above is

Public final class Gender extends java. lang. Enum {public static final Gender MALE; public static final Gender FEMALE ;}

We can also see that JDK also tends to use enumeration to define constants, such as java. nio. file. StandardOpenOption.

In this way, only MALE or FEMALE can be passed in for methods that accept parameters of the Gender type. No other options are available. This is the meaning of enumeration.