Re: Is this code "proper" use of extend?
CJ wrote:
But Mr Welch noted something which disturbs me about the entire
concept of OO. Specifically, Mr Welch wrote:
Extending classes you don't have control over can be a risky business.
What happens if the Java guys decide to add a "SignalAll" to the Vector
class? (highly unlikely, but this is just an example). If they not only
added that method in some future release but the Vector would call it's own
signalAll method at times, your version of the method could end up breaking
their code if it didn't happen to do just the right thing.
His statement is true for any base object that get extended, not just
core object of the language. Any object can be "enhanced" -- for lack
of a better word -- and the risk exists the "enhacement" conflicts
with an object extending it. Does not his statement belie the
"benefits" of OO, perhaps highlight a real danger in using OO?
You are exactly right. This particular danger is called, "making a class
heritable without planning for the consequences". It's a topic covered very
well, among other places, by Joshua Bloch in his vital /Effective Java/ book.
The problem is that when you make a class heritable, you are exposing much
more of its implementation to other folks, folks who don't know you, folks who
don't have your goals in mind or at heart, folks who can do surprising and
damaging things if you don't lock certain gates.
"I didn't realize that getFoo() could yield a completely different behavior if
its helper method barBaz() was overridden."
The prevention in that particular case is to declare the barBaz() method
'final', i.e., forbidden to be overridden. A well-designed heritable class
locks down behaviors that subclasses should not mess with. It does not call
overridable methods from constructors. It is very close with its access
privileges, rarely straying into package-private, much less protected or
public exposure. It also will change its exposed interface very, very rarely,
if ever. Superclass "enhancements" can break subclass behavior, too.
It seems we programmers just don't get power in a language without the
responsibility to use it wisely.
--
Lew