<snip>
On Sat, 22 Jan 2005 17:39:47 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> >>Which is why the use of an interface instead of a class makes
> >>no sense. It merely makes bad coding possible and does
> >>nothing else for you.
>
> Jack, your not saying using an interface in general is bad I hope?!? :)
</snip>
Absolutely not! That would be a real DOH! I have strongly advocated
that JERICHO and interfaces be implemented for Struts 2x.
<snip>
> I think I agree with the idea of not putting constants in interfaces as
> well. The idea of an interface is to describe a contract between an
> object and clients of that object. It doesn't seem to me that an
> interface then should contain any details that pertain to how it's
> constituent functions perform their actions, or how any client will
> actually make use of an object implementing that interface.
</snip>
Well put!
<snip>
> > If I have a constant pool in a class, i have to protect it from
> > instantiation (giving it private constructor) and give it a special name, so
> > it's clear for my co-developers, which both means more work to me. An
> > interface is uninstantiable by definition (since there are no classes which
> > implement a constant interface).
</snip>
The problem with this is that there *are* classes which implement a
constant interface. All someone has to do is code "public class
MyClass implements ConstantInterface" and you have the problem. I am
not sure why Leon thinks there are "no classes which implement a
constant interface". We may be miscommunicating here?
I am not sure what you mean by a "constant pool". I know about
"constant pool" as in new String("blah").intern(). I do know what
when you use a class as a "carrier" of constants, you merely use
whatever name you would with an interface, e.g. SiteConstants.java and
make sure their is a private constructor, e.g. private SiteConstant()
{};. I don't see the downside on this. I would think that typing
"private SiteConstant() {};" is far perferrable to typing your API
down for life to SiteConstant.
I think the whole thing comes down to Leon thinking that classes
cannot implement a constant interface, which they can and,
unfortunately do. The important thing, however, is that they can and
that means that your design will be flawed if you do that.
Am I getting you right, Leon?
<snip>
> ...this is a reasonable point! The only thing I would say Leon is that
> yes, I would think a decent name for a "constants class" would be a good
> idea (but that's *always* true of naming classes),
</snip>
This is no additional problem at all. Just use whatever name you were
using with the interface.
<snip>
> but as far as
> protecting it from instantiation goes, I would say: why worry about it?
> It seems clear that such a class shouldn't be instantiated, but
> there's no harm if it is, right?
</snip>
There is a "harm". This leads to the same problems as with an
interface. Not as drastic, but still there. Just using a private
constructor solves the whole problem and is very, very simple.
Jack
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
