Dale King said:
Well, saying that it is "obvious" when it is not obvious to those here
is not an effective way of shutting up. You basically are insulting
anyone that disagrees with you.
I'm assuming that the doctrine is merely being iterated as fundamental fact
without any thought.
With a completely open mind, it is obvious, at least, to me. No insult is
intended.
It seems to me that you have two assertions that you are trying to merge
into one and I fail to see how they are related. The assertions I see are:
- Concrete inheritance is evil
- Constructors should be private
Even if one agreed with the first one the second one does not follow
from the first. Even with no concrete inheritance you still need a way
to create concrete instances.
They are very much related, but again, I'm being torn between 'shutting up'
and writing a book chapter.
I dare not fall somewhere in between for fear of undermining the truth and
potentially confusing an audience.
For the first I would agree that concrete inheritance is quite often
abused and should be used less that it is, I do not agree that it is
always evil. For one thing every class in Java uses concrete
inheritance. Every object inherits some concrete implementations from
Object.
Yes, Java is intrincisally flawed. I intend to offer alternatives to
concrete inheritance, including the special case of java.lang.Object (which
ties the language spec., not just the API spec., to concrete inheritance).
The only justification for concrete inheritance is where a third party
dependancy exists - should you reimplement that dependancy (in this case,
the Java programming language) or concede to the brokenness? In cases where
you concede, I intend to provide a neat solution (isolating the brokenness).
You would concede in some cases because of a trade-off; sure, reimplementing
Java is extreme and reality is reality. It certainly pays to acknowledge
that it exists though. For the case of concrete inheritance without a third
party dependancy, there is no trade-off. You have written broken code with a
huge expense for no benefit. You may call it dogmatism; I call it a
fundamental rule - in much the say way that implementing a for loop like
this...
int x = 1000;
for(int i = 0; i < x * 10; i = i + 10){System.out.println(i / 10);}
.... is fundamentally broken compared to this:
for(int i = 0; i < 1000; i++){System.out.println(i);}
One offers a significant hit for no gain. Do you call the latter common
sense, and the former fundamentally broken? I do. The analogy is perfect,
despite all the attempts to prove it otherwise. There is also another
potential justification for concrete inheritance, but its validity is
subjective. That is, when you have unskilled people. How often have you seen
fundamental rules broken because they were misunderstood by their audience?
I see it often - it would have been better if those unskilled people were
never introduced to the fundamental rule.
I know of an example of a hashtable (which should have O(1) lookup time) has
been implemented as a list (which should have O(n) lookup and average
O(n/2)), however, it has been done such that lookup is O(n) and average
lookup is O(n). If this person were never introduced to hashtables, then
perhaps they would have used a conventional list/sequence and gained. I
think you might see why I question the validity of this argument (but it
should be presented nonetheless).
http://thedailywtf.com/forums/33738/ShowPost.aspx to see it for yourself.
I have thought about this topic (and many more related) in massive detail,
and I have spent many hours (perhaps weeks when added up?) discussing these
with people of high credibility (in fact, I'll bet you'd know of some of
them, but I care not to release their name without their permission). Please
understand that I choose not to undermine the amount of work (which is
nothing much more than verbal communication, scribble on paper and defending
my case on forums but not really defending it) by providing a 'half-arsed'
explanation. I also know that I am not on my own, because I read about
similar topics in places from others, but never to the detail that I think
it it deserves. I reserve the right to say "concrete inheritance does not
solve your problem" just as much as anyone (who I believe would be less
informed) reserves the right to say "concrete inheritance solves your
problem" without providing a sound basis for the assertion - majority vote
for concrete inheritance as a solution doesn't mean much to me. I proved
this once by asking an audience of Java developers what the difference, if
any, between a final and a constant is. 93% erroneously said no difference,
yet it's well documented in the language specification as distinct (and for
the record, I provide a practical example here
http://qa.jtiger.org/GetQAndA.action?qids=13). Although this was a somewhat
formal experiment of my hypothesis that majority vote means bugger all, I
see examples of it every day. Copernicus was right!
I find very little justification for your second assertion and you have
offered none.
I *really* should shut up now.
--
Tony Morris
Software Engineer, IBM Australia.
BInfTech, SCJP 1.4, SCJP 5.0, SCJD
http://www.jtiger.org/ JTiger Unit Test Framework for Java
http://qa.jtiger.org/ Java Q&A (FAQ, Trivia)
http://xdweb.net/~dibblego/