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]
