• Post Reply Bookmark Topic Watch Topic
  • New Topic

java constants using as interfaces  RSS feed

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is it a good practice of declaring constants belonging to different layers say Controller, Services, DAO etc inside a single interface using multiple interfaces for segregation of the constants as per the layer they belongs to for example as below:

 
Bartender
Posts: 1664
37
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Basically, you are referring to "Constant interface". It is considered as anti-pattern. I must confess that even I have used an interface within interface to keep all my constants in one of my old projects.

here is what wiki says : https://en.wikipedia.org/wiki/Constant_interface

Use of this pattern has a few other downsides:

  • It pollutes the class namespace with read-only variables that may not be of use.
  • 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).
  • 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.
  • Without an IDE that resolves where the constant are coming from, tracking it back to its containing class or interface can be time consuming.
  • A variable (representing an instance) of the interface is syntactically no more useful than the interface name itself (since it has no methods).
  • 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.



  • Having said that. Why are you using

    instead of simply
     
    Marshal
    Posts: 56605
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    No.

    Declare them in a class and use static import.import static resources.TestConstants.FIRST_UI_CONSTANT; etc.

    I don't think you can use interfaces inside interfaces like that; they would need public access. Also every field must have final status. There is something not quite right about using Strings like that. Consider an enumerated type instead.

    And welcome to the Ranch
     
    salvin francis
    Bartender
    Posts: 1664
    37
    Eclipse IDE Google Web Toolkit Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Campbell Ritchie wrote:
    I don't think you can use interfaces inside interfaces like that;


    It works fine:

    gives output

    However, I agree, enums are definitely way better.
     
    Saloon Keeper
    Posts: 7993
    143
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Even then, they're just floating constants. They don't actually belong to anything. Constants should be declared where they are used, that is, within the respective UI, Service and DAO classes.

    And I agree with Campbell, Strings are horrible and should probably be replaced with enums.
     
    Campbell Ritchie
    Marshal
    Posts: 56605
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    salvin francis wrote:. . .
    It works fine:
    . . .
    Move your MyTester class into a different package and then see whether it still works
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 7993
    143
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Only Outer would have to be public. All members of an interface are public by default. Fields are public, static and final by default.
     
    Campbell Ritchie
    Marshal
    Posts: 56605
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    salvin francis wrote:. . .
    here is what wiki says : https://en.wikipedia.org/wiki/Constant_interface

    Use of this pattern has a few other downsides:
    . . .
    . . .
    The word is spelt A‑N‑T‑I‑p‑a‑t‑t‑e‑r‑n.
     
    Campbell Ritchie
    Marshal
    Posts: 56605
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Stephan van Hulst wrote:Only Outer would have to be public. All members of an interface are public by default. . . .
    I forgot that bit.
     
    salvin francis
    Bartender
    Posts: 1664
    37
    Eclipse IDE Google Web Toolkit Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Campbell Ritchie wrote:Move your MyTester class into a different package and then see whether it still works


    Still works :
    Outer.java


    MyTester.java

     
    salvin francis
    Bartender
    Posts: 1664
    37
    Eclipse IDE Google Web Toolkit Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Ouch!! Stephan beat me to it , but OP too wrote "public interface TestConstants", so it too should work.

    Note to OP: Don't mind us discussing, We have all agreed on one thing: Use enums instead of such constants.
     
    Ranch Foreman
    Posts: 3071
    37
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    salvin francis wrote:Ouch!! Stephan beat me to it , but OP too wrote "public interface TestConstants", so it too should work.

    Note to OP: Don't mind us discussing, We have all agreed on one thing: Use enums instead of such constants.


    Unless the constants aren't related.

    I don't see the advantage of an enum for, eg:

    they're not related.

    It boils down to what exactly these constants represent.
     
    Ranch Hand
    Posts: 224
    12
    Eclipse IDE IntelliJ IDE Java Scala Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I agree wholeheartedly with the rest of the conversation here. Another consideration is: should these actually be in properties files rather than constants in code?

    Anyway I have experience with a legacy application where constants were declared in interfaces. I do not like the practice. It just makes your application seem cluttered. Every time you turn around a class has some class signature with something like "implements ApplicationConstants" and there's all these interfaces lying around which aren't actually interfaces. Any new devs coming in to try and maintain it end up having to go through the extra learning curve of learning what to filter out as they go through diagnosing a bug or whatever they're doing.
     
    Ranch Hand
    Posts: 175
    17
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Since Java 8 encourages us to declare relevant static methods in appropriate interfaces, I presume that it’s also a good idea to declare relevant static fields in appropriate interfaces.

    According to this article, before Java 8, we were forced to declare relevant static methods in a companion utility class, for example, the java.util.Collection interface has a companion utility class called java.util.Collections. If the java.util.Collection interface was written in the Java 8 era, I presume that the static fields and static methods declared in the java.util.Collections class would have been declared in the java.util.Collection interface.
     
    Campbell Ritchie
    Marshal
    Posts: 56605
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Joe Bishara wrote:Since Java 8 encourages us to declare relevant static methods in appropriate interfaces, I presume that it’s also a good idea to declare relevant static fields in appropriate interfaces. . . .
    Don't know. But remember that up to Java7 all interface fields were implicitly static.
     
    salvin francis
    Bartender
    Posts: 1664
    37
    Eclipse IDE Google Web Toolkit Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Campbell Ritchie wrote:Don't know. But remember that up to Java7 all interface fields were implicitly static.

    Nothing was changed in java8 for interface fields. They are the same as before (Implicitly public, static and final)

    Joe Bishara wrote:
    Since Java 8 encourages us to declare relevant static methods in appropriate interfaces, I presume that it’s also a good idea to declare relevant static fields in appropriate interfaces.

    According to this article, before Java 8, we were forced to declare relevant static methods in a companion utility class, for example, the java.util.Collection interface has a companion utility class called java.util.Collections. If the java.util.Collection interface was written in the Java 8 era, I presume that the static fields and static methods declared in the java.util.Collections class would have been declared in the java.util.Collection interface.


    Collections is concrete class, it has utility methods for all collections that come under this umbrella. Collection is an interface which gives a certain 'behavior' to to AbstractCollection, AbstractList, AbstractQueue, etc..
    There are just 3 public fields inside Collections class which i don't think are relevant in the Collection interface. I fail to understand how this is relevant to current discussion of constant fields. Maybe you meant something else ?
     
    Joe Bishara
    Ranch Hand
    Posts: 175
    17
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    salvin francis wrote:I fail to understand how this is relevant to current discussion of constant fields.

    According to this article,
    ...the java.util.Collections class is a companion to the java.util.Collection interface, and declares static methods that would be more appropriate in the relevant Java Collections Framework interfaces.

    For example, the constant public static final Set EMPTY_SET and the utility method public static final <T> Set<T> emptySet() declared in the java.util.Collections class would be more appropriate in the java.util.Set interface.

    In the Java 8 era, since utility methods (static methods) can now be declared in an interface, constants used by those utility methods should be declared in the same interface. For constants that are not relevant to utility methods in an interface, an enum might be a more appropriate place to define them.
     
    salvin francis
    Bartender
    Posts: 1664
    37
    Eclipse IDE Google Web Toolkit Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Joe Bishara wrote:In the Java 8 era, since utility methods (static methods) can now be declared in an interface, constants used by those utility methods should be declared in the same interface. For constants that are not relevant to utility methods in an interface, an enum might be a more appropriate place to define them.

    Thanks for the clarification here. It appears that you are referring to how we should classify the constants whether it should lie in an interface or whether it should lie in an enum given that now interface too will have methods which are either default or static.

    My perspective here is that it still does not change a lot. You can still have a class which can store different types of constants :


    (static import is your friend here)

    I would personally use an enum where similar type of related data is used:



     
    Stephan van Hulst
    Saloon Keeper
    Posts: 7993
    143
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    salvin francis wrote:My perspective here is that it still does not change a lot. You can still have a class which can store different types of constants :


    (static import is your friend here)


    Except that in this case, you shouldn't import anything; these should be constants declared within the UI, not a separate class. Declare constants in the context where they're used.
     
    salvin francis
    Bartender
    Posts: 1664
    37
    Eclipse IDE Google Web Toolkit Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Stephan van Hulst wrote:Except that in this case, you shouldn't import anything; these should be constants declared within the UI, not a separate class.

    Point taken, this is indeed a poor example from my end.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!