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]
