OO should break when broken(was re: the benefits of immutability)

["Michael St . Hippolyte" <address@hidden>]

As I thought about the ColoredCircle example and its
alleged indictment of Java and/or OOP I realized 
something  totally obvious yet as far as I know not 
remarked upon up to now: ColoredCircle perhaps *should*
break, since it violates the basic principles of OO, not
to mention good programming of any persuasion.

The problem is very basic: a general property such as
color should not be maintained in a specialized 
subclass.  The only properties in the subclass should 
be properties not found in any of its superclasses.  
While color was chosen just as an example, and any other
arbitrary property could have been chosen just as easily,
the OO paradigm elminates most such paradigms from 
consideration.  If Circle cannot correctly deduce equality
with a subclass instance, then the object model is 
seriously broken; some crucial bit of information is being
stored in the wrong place.

A Circle class implies a class hierarchy defined by shape, 
and it's not clear to me what kind of shape you could 
meaningfully subclass from Circle; what can you change
geometrically about a circle without making it not a 
circle?  On the other hand, geometrically a circle is a 
special case of ellipse.  Clearly, any geometrically valid
test for equality between ellipses would work on circles as
well, so there shouldn't be any need for Circle to override
the equals method, and if it does override equals (for
efficiency reasons perhaps) it should yield the same 
outcome.

The point of polymorphism is to be able to ignore 
differences.  Subclasses should faithfully mimic the
broader classes being handled, which can't be done if a
subclass's special properties cannot be safely ignored.

The real problem that ColoredCircle exposes is that OO 
techniques can actually hurt you when the object model is 
flawed.  This is the tension that drives refactoring;
experienced OOP programmers detect such problems
(eventually) and use that information to refine the object
model.


Michael

-----------------------------
Michael St. Hippolyte
http://www.bentodev.org