Re: Where do you keep contants in Interfaces or in classes?
On 31 $B'^'Q'b(B, 02:44, Lew <l...@lewscanon.com> wrote:
Stefan Ram wrote:
(1) Constants can only be kept in interfaces,
Which is known as the Constant Interface Antipattern. It's also not true.
classes might have $B"d(Bfinal fields$B"c(B or $B"d(Bconstant variables$B"c(B, but these are not
called $B"d(Bconstants$B"c(B in Java.
Acxtually, they are, if they conform to the JLS's rules for what is called a
"constant variable", which if statis is the same thing as a "constant".
JLS3, 4.2.4 mentions constants in classes:
$B"d(BOther useful constructors, methods, and constants are
predefined in the classes Float, Double, and Math.$B"c(B
I admit that this contradicts my previous statement (1). But
Uh, yeah, only completely.
this might be the only place, where the JLS3 mentions
$B"d(Bconstants in classes$B"c(B.
Section 15.28, "Constant Expression", provides the definitive definition:
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.htm...>
Qualified names of the form TypeName . Identifier that refer to constant variables
In other words, a static final variable that refers to a constant.
It also references section 4.12.4,
We call a variable, of primitive type or type String, that is final and
initialized with a compile-time constant expression ($B!x(B15.28) a constant variable.
Not only are constants used in classes, but it's a bad idea to define
constants in interfaces.
--
Lew
Ok I know the answer to my question, which at least for me appears to
be fair. I've started to search and found this article:
http://java.sun.com/j2se/1.5.0/docs/guide/language/static-import.html,
I know a couple of people have already mentioned static imports but i
would like to quote the main argument against constant in interfaces:
*******
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.
*******
So, I'm changing my previous decision to use interfaces as the place
to keep constants. Instead I will use the following approach:
package org.megaware.constants;
public final class Constants {
public final static int GENERIC_INT = 0;
// some other generic consts here
public final static class Network {
// some other Network consts here
public final static int DEFAULT_PORT = 55888;
}
public final static class Gui {
// some other GUI consts here
public final static String APP_TITLE = "Megaware";
}
}
I believe this is the best approach for any types of constants that
you want to use across your application. Another argument against
interfaces is that you can extend them as opposed to the final classes
(note that in my example). Why the possibility to extend interfaces
that contain constants is bad? In fact it is worse than flying over
Atlantic on a brutally hard economic seat with something they call
beef y penne for dinner, brrr... Imagine you have interface called
IGenericConstants then you decide that you need some network constants
and extend IGenericConstants with INetworkConstants. As a result all
your generic constants propagate to network constants container and a
couple of months later you notice that your junior programmer has
mistakenly used constants defined in IGenericConstants all over across
his newly written network class (just because the values suited his
needs and he didn't want to add new constants to INetworkConstants, so
why not just using INetworkConstants.CONSTANT_FROM_GENERIC?). Of
course this wont lead to a bug, or...? Another week later you spend a
sleepless debug nightmare night. Finally you decide to annotate
INetworkConstants and ready to tear your hair out because Ben, another
programmer from network team, has refactored some networking code
including INetworkConstants interface and overridden
INetworkConstants.CONSTANT_FROM_GENERIC field with some other value.
The scenario can be easier to imagine if you take a look on the
following code:
public interface IGenericConstants {
public final static int GENERIC_INT = 0;
}
public interface INetworkConstants extends IGenericConstants {
public final static int GENERIC_INT = 10000; //Ouch thats not what I
want!
}
The approach I suggest:
public final class Constants {
public final static int GENERIC_INT = 0;
// some other generic consts here
public final static class Network {
// some other Network consts here
public final static int GENERIC_INT = 10000;
}
}
prevents from such bug