Interfaces with static fields in java for sharing constants

Question

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

User · Answer

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  quot interface quot  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 lt Decision gt  compareCars List lt I Somecar gt  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

User · Answer

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  quot interface quot  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

User · Answer

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

User · Answer

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 lt Decision gt  compareCars List lt I Somecar gt  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

[java] Interfaces with static fields in java for sharing 'constants'

Examples related to java