Re: Another OO Problem (and thanks for the input I received so far)

From: Programmer Dude (Chris_at_Sonnack.com)
Date: 11/03/04 

Date: Tue, 02 Nov 2004 17:46:30 -0600

Catching up on cached-for-later posts...

TGOS writes:

> I'd say an Ellipse is a sub-class of Circle. Although mathematically
> seen, a Circle is a special kind of Ellipse.

OTOH, mathematically a circle can be defined with no reference to an
ellipse.

> The question is: Do we use inharitance to specialize behavior from
> general to specific, or do we use inharitance to extend behavior.

Yes. (-: Things in life are rarely just one thing or the other.

Sometimes inheritance is useful for specializing, sometimes it's useful
for extending. Depends on your goal.

> I think, the last one is true. A sub-class extends, so the sub-class
> must offer more behavior than the super-class. Now who has more
> behavior, a Circle or an Ellipse? A Circle just has a radius, an ellipse
> has two of them. A Circle can just change the size, an Ellipse can
> change the size and the shape.

Doesn't it really depend on *why* you are creating classes for circles
and ellipses? If I were greating GUI objects, I might consider an
ellipse to be an extension of a circle due to the extra fields needed
to implement the thing. In some other situation, I might feel that
a circle needed to be a specialized ellipse (although I confess I
cannot think of such a situation off the top of my head--maybe sort of
mathematics demo?).

> But the problem is: What if you call a method, that expects a Circle
> as argument and receives an Ellipse. Will it be able to cope with an
> Ellipse?

WHY is it expecting a circle and not something more general, such as
a "Shape"? But if such a thing occurred, consider this: what's that
function concerned with? Placing a circle/ellipse on the screen?
Using what technique? Center point and extent? Bounding rectangle?
It all makes a difference. If center point, well, ellipses don't
have one in the same way a circle does--neither would a typical
implementation of a square/rectangle. So in this case, a developer
might need to "fake" a centerpoint field in classes were the real
object lacks a defined center point.

OTOH, if you were using bounding rectangles, any shape should be able
to place itself given that rectangle.

So, as usual in this game, It All Depends!

>> String ... StringBuffer ...
>
> How to create a String from a StringBuffer then?
> The String can't access the array of the StringBuffer and the other way
> round.
>
> Of course I can use a helper class, StringStorage, and pass that between
> String and StringBuffer. But then, what stops programmers from creating
> their own StringStorage object, create a String with it (just like
> StringBuffer would do) and then modify it - and thus modifying the
> immutable String?

Make StringBuffer and String inherit from a private base class that,
as you suggest, handles the storage needs. StringBuffer presents a
mutable interface, String does not.

> Then again, StringStorage is not necessary. A StringBuffer itself can be
> the storage for a String, and String just doesn't allow access to any
> editing methods of StringBuffer.

That too. Many paths to a furless feline.

> Don't underestimate what you can all do with a hammer ^_^

Right! But not all those tasks are *elegantly* done! (-:

Relevant Pages