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. <context switch/> 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 > <[EMAIL PROTECTED]> 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: > > > <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 > > > > > > > > > > > --------------------------------------------------------------------- > > 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]
