Originally posted by Ilja Preuss:
Can you give us an example of an occasion where inheriting the type from a class got you into trouble? Did you violate LSP, or something?
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Originally posted by Michael Ernest:
LSP -> Liskov Substitutability Principle
I like Bertrand Meyer's definition: a subtype should require no more and promise no less than its supertype.
Originally posted by Mr. C Lamont Gilbert:
Yes. After considerable thinking I can't come up with a scenario where a child class overrides a parent class's implementation without violating LSP
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Originally posted by Ilja Preuss:
What about overriding toString?
Originally posted by Ilja Preuss:
Notice that Meyer talks about *promises*. A method doesn't need to *promise* any or all of it's implementation details. For example, HashMap might be implemented in a way that delivers keys in a certain order, but it doesn't *promise* that it does. So an implementation that delivers in a different order doesn't break LSP.
In fact, Meyer is the inventor of DBC and the language Eiffel, which has a syntax for specifying the "promises" (called the contract).
"I'm not back." - Bill Harding, Twister
Originally posted by Ernest Friedman-Hill:
...This happens when you use a concrete type as a method parameter, or as a method return type.
If a concrete type has a constructor, and also there are methods that return that type, then you can never let that method return a polymorphic type without...wasted space.
So this is why a language that allowed methods to only accept and return interface types seems to me like an excellent way to help young designers "do the right thing."
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Originally posted by Ernest Friedman-Hill:
To answer Ilja's question, the concrete inheritance problems I've gotten into have all been of the "refused bequest" kind. They're not problems that happen because of concrete inheritance, so much as problem that occur because you're forced to use concrete inheritance. The happen when you use a concrete type as a method parameter, or as a method return type.
So this is why a language that allowed methods to only accept and return interface types seems to me like an excellent way to help young designers "do the right thing."
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Jim Yingst:
...
Sometimes, but not often. For example things like Enums would be fine with the default implementations of equals() and hashCode() since there's only one instance per value in a JVM. On the rare occasions the current defaults (in Object) are desireable behavior it would be very simple to explicitly provide implementations equivalent to those current defaults. Eg.
The last could be facilitated with a convenience method put somewhere like the System class.
Note that Enum does in fact override equals() and hashCode() with these implementations - adding only a final, so that subclasses don't waste time with alternate implementations.
Originally posted by Jim Yingst:
Cloneable is more problematic, and personally I never use clone() anyway. If I were able to redesign Java's cloning though, I'd probably take clone() out of Object and put it in Clonable where one would expect to find it - then provide a couple utility methods in System which could be used for typical implementations, like:
Probably they'd best be native code implementations, much like we now have in Object's clone(). I haven't really thought this through though since I don't generally care much about clone(), other than to avoid it.
[ September 15, 2005: Message edited by: Jim Yingst ]
So this is why a language that allowed methods to only accept and return interface types seems to me like an excellent way to help young designers "do the right thing."
Originally posted by Mr. C Lamont Gilbert:
Nothing beats a good teacher.
...and she wields a cudgel.Her name is experience.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
You must be one of the fortunate few that never makes a bad decision...Depends on how you treat her, I'd say. I welcome her lessons, and I don't remember being hurt.
Tony Morris
Java Q&A (FAQ, Trivia)
Originally posted by Ken Blair:
I am meeting a great many programmers with 10+ years of experience and only 1 year of knowledge.
Originally posted by Steve Morrow:
You must be one of the fortunate few that never makes a bad decision...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ken Blair:
When experience comes in the form of a demo bombing in front of the company's owner, it hurts.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ken Blair:
Maybe I'm misunderstanding but I don't think that's quite the same thing. Where I work I've actually found that, in general, there's more of an attitude of empowerment than micromanagement. What I meant is that I'm finding I gave the average programmer much too credit. They don't bother to see how things work under the hood, don't bother to develop good practices or learn proper design principles, in general just don't bother to learn. They learned the bare minimum, the first year, and stick with that. The worst part is, most of the time they treat anything they don't know how to do as impossible, saying it can't be done so that their inferior method that they already know seems acceptable.
That's what I mean by people with 10 years experience, 1 year knowledge. Sure, they've been doing it for 10 years, but they haven't learned anything in the last 9.
Those who dance are thought mad by those who hear not the music. This tiny ad plays the bagpipes:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|