From: Vincent Manis <vmanis@...>
Date: 2011-04-08T07:42:30+09:00
Subject: Re: Hash Surprises with Fixnum, #hash, and #eql?


On 2011-04-07, at 09:06, Brian Candler wrote:
> Eventually you come to realise that a lot of what is taught in object 
> oriented classes and textbooks is tosh :-)

And a lot of what is done by practitioners using object-oriented languages
is tosh as well, I know, I've seen it. (You haven't lived until you've had 
to review a C++ class with 9-way multiple inheritance, without using rude 
words!)

The Circle and Ellipse example is a good one. In fact, a Circle is no more 
than an Ellipse with a constraint (eccentricity = 0, or, equivalently, the 
two foci (`focuses') of the Ellipse are at the same point). So in almost 
all cases, I wouldn't have two separate classes, but one, Ellipse. 

In the case of Complex and Float, the operative design principle is the 
Liskov Substitution Principle, which can be roughly stated in OO form as
`you can derive class Sub from class Super if and only if every instance 
of Sub can be regarded as an instance of Super'. 

Thus it's perfectly reasonable to derive JetPlane from Airplane, because 
every JetPlane should be able to respond to all Airplane operations. 
However, you can't derive Airplane from Wheel, or Wheel from Airplane, 
even though there is some connection between wheels and planes. Like all 
design principles, there are exceptional cases where the LSP doesn't apply, 
but it seems to be the best heuristic for permissible subclassing.

In the Complex/Float case, the LSP tells us that we _could_ consider Float 
a subclass of Complex (because every Float is, as has been pointed out, a 
Complex with an imaginary part of zero), but that Complex can't reasonably 
be considered a subclass of Float. A good designer would go further and say
`yes, the LSP allows me to derive Float from Complex, but that's a waste of 
storage, because it means I must store imaginary parts that are always zero.'
Thus a better design (which Ruby follows) derives Complex from Numeric.

That's the OO theory, and it's not tosh :)

-- vincent manis