-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Carl Smith wrote:
Thanks all for the hot discussion. However, the discussion has gone too far off my original question. I suggest not to discuss whether or not we should have an interface just for constants, instead I have decieded to use the constant interface (no matter it is good or not, I beleive it will not affect my application performance), then which one of the following two classes is prefered to access the constant. I have seen several answers which seem to agree with my thoughts. Thanks.
public interface MyInterface {
public static final String YES = "yes";
}
public class WayOne {
public void myMethod(){
String yes = MyInterface.YES;
//...
}
}
public class WayTwo implements MyInterface {
public void myMethod(){
String yes = YES;
//...
}
}
David Bolsover <[EMAIL PROTECTED]> wrote:Wow.. I'm off line for a day .. and WWIII breaks out..
My reference to Joshua Bloch seems to have gotten the list a bit steamed up.. any chance that peace might break out some time soon?
db
-----Original Message----- From: Leon Rosenberg [mailto:[EMAIL PROTECTED] Sent: 23 January 2005 15:08 To: 'Struts Users Mailing List'; 'Dakota Jack' Subject: [OT] Re: constants interface
Hello Jack, list,
Ok, maybe I shouldn't write things like "No, as usual, you miss my point.", but actually this is true, which is I assume more my fault, as I fail to explain my thoughts understandable, then yours. It just always happens with you, Jack :-)
So I beg my pardon for the rude tone of my message, but not for the content :-)
Actually you just need to google on "definition of java interface" to see that sun's java tutorial prefers my view of constant declaration :-)
http://java.sun.com/docs/books/tutorial/java/concepts/interface.html
... Within the Java programming language, an interface is a device that unrelated objects use to interact with each other...
And then:
... You use an interface to define a protocol of behavior that can be implemented by any class anywhere in the class hierarchy. Interfaces are useful for the following:
Capturing similarities among unrelated classes without artificially forcing a class relationship. Declaring methods that one or more classes are expected to implement. Revealing an object's programming interface without revealing its class. ...
Using interfaces for constant declaration perfectly fit into: Capturing similarities among unrelated classes without artificially forcing a class relationship, doesn't it?
On the other hand the definition of a class:
Definition: A class is a blueprint, or prototype, that defines the variables and the methods common to all objects of a certain kind.
What I'm really amused about, is how you are changing your mind inbetween of discussions. Some time ago I have started a thread on JSTL / EL support in struts, pondering it would be an architectural break to the MVC architecture, and therefore should be banned from struts. My point was, EL gives the user the possibility to break the paradigm, and if the user has the possibility he would use it. You was one of those who was opposing it.
Now You are telling us:
The point of good design is to not have to depend on good coders.
This infact means that struts isn't good designed, and neither java itself is, Or how would you explain java.awt.Adjustable or further dozens of interfaces which define constants ?
Regards Leon
-----Ursprüngliche Nachricht----- Von: Dakota Jack [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 23. Januar 2005 06:57 An: Struts Users Mailing List; [EMAIL PROTECTED] Betreff: Re: [OT] Re: constants interface
Yah, you're right. But what gets me going is not code issues. I could care less about disagreements about that. I should ignore things like " No, as usual, you miss my point. ", but I just cannot get used to that sort of thing, it seems. I'll try harder to ignore them. I am sure my getting ticked off at rudeness gets old to others too. I am just not used to it. The only place I get it is on these lists.
Jack
On Sat, 22 Jan 2005 22:52:02 -0500, Frank W. Zammetti wrote:
Wow, this is getting a little hostile fellas...
It's not like we're trying to decide whether Heidi Klum is
hotter than
Tyra Banks (she is, but not by much), and we're not trying
to decide
whether Enterprise should be cancelled (I say one more
season to right
the ship), and it's not like we're trying to decide if the B5 movie should have Peter Woodward playing Galen (I will blow up
the studio if
he's not).
We're just talking code here. Heck, it's not even a major
issues no
matter which side of the fence your on.
Let's pull back from the brink of WWIII here :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Dakota Jack wrote:
On Sun, 23 Jan 2005 01:49:56 +0100, Leon Rosenberg 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.
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.
What i really don't understand, is, why is an interface, which is not describing a contract, a problem?
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?
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.
I am afraid I have not seen any "evil" in using the class as a "constant holder". What is the evil?
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.
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.
So why should an interface only be able to describe objects and components and not other 'describeables' like protocols ?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ------------------------------
"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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
======================================================= This message has been scanned for viruses and dangerous content using Vet Anti-Virus Protection and is believed to be clean. =======================================================
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term'
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
