Re: Making String variable and value available for all Classes
"Mike Schilling" <mscottschilling@hotmail.com> wrote in message
news:h826fl$dat$1@news.eternal-september.org...
Lew wrote:
Lew wrote:
I don't agree that constants in the interface make sense even for
the
DOM scenario. Interfaces exist to be implemented, to provide type
identification. A separate static-member class is a better choice
for constants, e.g., for the DOM I'd recommend a NodeConstants
class.
Mike Schilling wrote:
You've stated your opinion pretty strongly. Can you give the reasons
behind it?
For a better explanation than I can provide, first I refer interested
parties to Joshua Bloch's /Effective Java/ Item 19
http://books.google.com/books?id=ka2VUBqHiWkC&pg=PA98&lpg=PA98,
That item criticizes interfaces that do nothing but define constants (i.e.
that don't define any methods.) In fact, it goes on to say:
If you want to export constants, :there are several reasonable choices.
If the constants are strongly tied to an existing class or interface, you
should add them to the class or interface.
I tend to agree with this. A class or interface is, among other things, a
namespace. If you want to define a constant that's associated with that
namespace, the simplest way to make that association clear is to make it a
member of that interface. Creating a separate class to hold it simply
make life more difficult for a developer trying to learn how to use the
interface.
I have been programming in Java since 1995, I think it was. At the time, as
a bunch of ex-C and C++ programmers, we were looking for the preprocessor
directives for #defining constants. We were told, "oh, you define constants
as public static final xxx in an interface."
Ok, that works. We used it liberally, and never really had any problems with
it. Then some years later, that practice was assailed as an antipattern.
While I understand the theoretical arguments, I haven't encountered any
situation where it would come back and bite us. Still, to avoid being
considered a rube, I now define constants in classes instead. If the
constants need to be shared across classes, then it either needs to be a
base class, inherited by all classes that use it -- assuming that they don't
need to inherit from something else. Multiple inheritance is supported for
interfaces, but not classes. In that case, you need a "has-a" relationship,
which is somewhat less intimate.
Things are somewhat improved today with enums, but public static final
constants are still a bit of a practical conundrum for me.