Interfaces For Defining Constants Interfaces For Defining ConstantsAssume you have a large (WhatIsLarge? ?) set of constants, e.g. protocol parameters, you need in separate contexts in your code, by multiple StakeHolders.
You of course want to have symbolic names for the constants, to avoid mismatch and errors of using the values all over your code.
Solution
To separate the definition of constants and the usage of these constants, define the constants in an interface. This provides an own NameSpace for the constants which can then be used by multiple "StakeHolders", including
The constants are not really parameters of a protocol, but an integral, defined part of a protocol specification. Using an interface for specifying such constants seems natural to me. -- ThomasWeidenfeller
Of course. In EnumeratedTypesInJava people try to work around the non existing enum implementation in Java. They need features, which include:
InterfacesForDefiningConstants , on the other hand, is all about values. One is just looking for symbolic names and grouping for some values. The values matter, but typing the same number several times in different parts of the code is not a good idea. The values even don't necessarily have to be some kind of enumeration.
Assigning symbolic names to the constants, and group them, could also be done with some C-style enumeration type - if it would be in the language. Or with C-like macros - if macros would be in the language.
This seems to be a violation of data encapsulation. Constants only have meaning in relationship to the variables that acquire their values. If the variables are well encapsulated, then the constants can be as well. If you need to use the same constant in multiple classes, I would review your class structure. It sounds like a code section that needs simplification. --WayneMack
Re: Violation of data encapsulation
Well, maybe yes, maybe no.
I've used also this idiom for protocols and for data base schemas. It looks a clear way of specifying external dependencies with very little work. Nevertheless, I'm still looking for a pattern that suits better to the case of data base schemas. --JoseGAlejandre
I am confused on this. Perhaps a small example might help. Why 'interfaces' instead of normal objects?
So you can shove the constants into the namespace of your classes by implementing the Interface. --MartinSchwartz
public interface FooConstants {
int cDog = 1;
int cCat = 2;
int cMouse = 3;
}
public interface BarConstants {
int cHouse = 1;
int cVilla = 2;
int cPalace = 3;
}
public class FooBar implements FooConstants, BarConstants {
...
switch ( barType ) {
// fully qualified form:
case BarConstants.cHouse:
// abbreviated form:
case cVilla:
...
}
...
}
[Ew--gross. (Somebody needed to weigh in on the opposing side.) If you ever do
that, you might want to specify in the contract documentation that clients of
FooBar must not depend on the publicly visible fact that FooBar implements
FooConstants?.
Actually, in Java 1.5 you can now say something like "import static FooConstants?.*" to accomplish the same simplification of the code without changing the public interface of your class.
-- DanielBarclay?]
The only advantage of using interfaces is that you don't need to retype the interface name everywhere that a constant is used *if* the class using the constants interface 'implements' that interface (using the term implements loosely here, since it's not really implementing anything). The disadvantages of polluting your classes with these 'interfaces' far outweighs the advantage, especially if the constants are only implementation detail (e.g. not passed to or returned from methods of the interface/implementation class). It might make sense to define the constants in the interface though, if they are part of the contract for that interface (i.e. expected parameter or return values from methods of that interface). The can be better done with (often final) classes (IMHO), e.g.:
public final class DoorState? {
'' private DoorState?() { ; } // prevent instantiation of this class.
'' public static final int OPEN = 0;
'' public static final int CLOSED = 1;
'' public static final int AJAR = 2;
}
Better still use the JavaTypeSafeEnum? idiom.
P. J. Lewis
By using interfaces to define constants (unless actually applicable to the interface), you lose name space. By using a final class to define global constants, you do not lose name space (yeah, I hate using classes for namespace, but lacking a real alternative in Java, you have to work with what you got).
How do you lose name space? Interface A-prime defines some constants without defining an actual protocol (i.e. real interface, the interface is present only to define constants), class A implements A-prime, class B derives from A, and class BB derives from B...now class BB references a constant from A-prime without qualification (e.g. A-prime.constant), time to start searching!
I don't see why you can't use:
class Constants {
private Constants()
{
}
public static final int A_CONSTANT=5;
etc.
}
Interfaces for namespace purposes only gains you brevity, and you can achieve some brevity like this:
Constants c; something(c.A_CONSTANT);
Maybe this is all moot now that 1.5 is out, I haven't looked into enums yet.
CategoryInterface Category: JavaIdioms
This page mirrored in JavaIdioms as of April 29, 2006