<snip>
On Sun, 23 Jan 2005 01:49:56 +0100, Leon Rosenberg
<[EMAIL PROTECTED]> wrote:
>
> > 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?
>
> No, as usual, you miss my point. As for your question, I know that it's
> technically possible for a class to implement a constant interface. It's
> also technically possible to write something like
>
> String a = "blah";
> String b = "blah";
> if (a==b){
> //do what you want.
> }
>
> Both is possible, both would work, and both is crap.
</snip>
No need to be "snippy" even if I am snipping. Okay, you did not think
a constant interface could not be implemented. You only thought it
would be "crap" coding to do so.
I think you are applying old-school procedural programming rules which
turned out to be unworkable and which led to the OOP (Object Oriented
Programming) model. The point of good design is to not have to depend
on good coders. If you want to make sure you can change the
implementation of a class, then you cannot rely on the assumption that
an interface will not be implemented. You cannot rely on the
assumption that you won't have to deal with "crappy" coders. The
*point* is that once you lock the API into the possibility you have to
live with the possibility.
<snip>
> What i really don't understand, is, why is an interface, which is not
> describing a contract, a problem?
</snip>
Well, I listed the problems that Joshua Bloch gave. I agree with
them. You don't agree with them? If not, what is your response to
the list of problems?
<snip>
> I think it is not a greater problem, then
> a class which does nothing, like your constant_holder_class would be. So we
> have two equal evils, and I prefer the lesser evil, the
> having__constant_holder_interfaces__evil.
</snip>
I am afraid I have not seen any "evil" in using the class as a
"constant holder". What is the evil?
<snip>
> Imagine following situation: I have a legacy system (lets call it foo),
> which I have to use in my application. Let's imagine it speaks xml over
> http. The legacy system has a set of parameters it undestands. Now, when I
> write a driver for this system, I would have something like this.
> IFooDriver - interface describing the driver, for use by the rest of my app.
> FooDriverImpl - my implementation of this driver, maybe
> FooSpecificDriverImpl.
> FooDriverFactory and some needed data classes would exist also.
>
> Lets further imagine we have 2 parameters, username and password. Since i
> don't want to use
> them as String, I want to create two constants:
> public static final String PARAM_USERNAME = "username";
> public static final String PARAM_PASSWORD = "password";
>
> Where do I place those constants?
>
> In my approach, I would create an interface IFooConstants with both
> constants,
> and refer in FooDriverImpl by the full name.
>
> In your approach, there would be FooConstants class with same constants.
>
> The difference seems to be very small, only an 'I' in the class/interface
> name.
</snip>
The difference actually is huge. You apparently think there is no
difference because you do not implement the interface but only refer
to the constants by FooConstants.USERNAME and so on. If this were the
only possibility, you would be right. However, SOMEONE ELSE might
well implement the interface and now you have the whole panoply of
problems we have discussed. You are, again, assuming that you only
have non-"crap" coders. The whole design problem is predicated on the
fact that you can only treat your API as protected as your exposure
and you expose the *heck* out of the API and then seem to want to
depend on the good will of the coders. That might be okay if you live
in your own little insular world where you control everything. That
is design disaster if you live in a world where other people make
decisions without you dictating to them, other than by design, what
they can and cannot do.
<snip>
> So why should an interface only be able to describe objects and components
> and not other
> 'describeables' like protocols ?
</snip>
The job of interfaces are to create types and to define their API
exposure. The job, in short, is to create an interface that the user
can depend upon. This interface should be implementation ignorant,
i.e. should leave the coder free to implement the interface as
desired. Your interface, when used, ties the coder to an
implementation detail. This is classically considered to be a bad and
to be a design mistake. I would like to be gentle and to use some
kind words to end this, like I did last time, but, learning from the
past, let me say that you are just plain flat mistaken here in my
opinion. If you don't believe me, and you don't believe the guy who
is in charge of design for the Java platform (who rues Java having
done otherwise in java.io.ObjectStreamConstants) then perhaps you
could address the real question of why it is okay to have an interface
tied to implementation details? I hate to even sound unflexible, but
arguing for interfaces injecting implementation details is so
anti-good-design I cannot take it too seriously and I have to admit
that my flexibility is embrace your sort of design discussion.
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]
