in reply to The Accessor Heresy

A few years ago, it was easy to get into immense flamewars with OO guys over a Circle class and its relation to an Ellipse class. It's probably just as easy now, but I quit paying attention. "Which inherits from which?" was often the point of contention.

The OO'ers would contend that Circle is the base class because it contains less data. The mathematicians would scoff, pointing out that a circle is a degenerate case of an ellipse.

It seemed to me that the OO example Circle class was chosen without enough domain knowledge, and that the mathematicians did not appreciate the need to save one number's worth of storage.

The OO is-a rule was ignored by the OO crew. Any circle is-an ellipse, but not every ellipse is a circle. That makes Circle a specialization of Ellipse, hence a subclass of it. It's uncommon in ordinary CS problems for a specialization to require less data than the base class.

There, I've gone and whacked that ol' hornet's nest again ;-)

P.S. Accessors are a fine thing when there is inheritance and method implementations in the base class.

After Compline,
Zaxo

Replies are listed 'Best First'.
Re^2: The Accessor Heresy
by Anonymous Monk on Nov 28, 2005 at 18:47 UTC
    It's uncommon in ordinary CS problems for a specialization to require less data than the base class.

    Really? That doesn't seem to be my experience...

    Off the top of my head:

    Graphics: Square isa Rectangle isa Polygon Line isa Curve Circle isa Elipse isa Curve

    Data Types: PrimeNumber isa Unsigned Int isa Int isa Real isa Complex String isa ArrayOfObjectTypeCharacters

    Unix I/O: TTY isa CharacterDevice isa IODevice isa FileIOObject (TTY is much simpler than generic character devices, and character devices are much simpler than generic I/O devices. FileIOObjects are a simpler abstraction, however...)

    In general, I find that base classes are usually often more general (and more complex) than specializations, since the point of a generalization is to encompass a wider number of possibilities. General algorithms are more abstract, but specific algorithms tend to more efficient. For example, it takes only two points to specify a line; but an infinite number of points are required to specify a general abstract curve. If you use a Curve object where a Line would do, you've used infinitely more storage space than necessary. ;-)

    I've never been a fan of OO, largely because of code like this:
    @abc=$x->$y(@z);

    It's now so abstract that the code doesn't actually tell me what method is being called, what class that method comes from, and what data is being passed into the (unknown) method. It's all decided at run time; so the only way to know what it will do is to run it, and see what data is reaching that section of the code. That's no fun.

    --
    Ytrew Q. Uiop

[reply]
[d/l]
      Square isa Rectangle isa Polygon

      Not quite. Square is both a Rectangle and a Rhombus, both of which are Parallelograms which isa Quadrilateral which isa Polygon. In addition, Square->is_regular_polygon() is true where none of the other classes mentioned in this listing can make that claim. is_regular_polygon() would be a method of Polygon.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
        Sure. I'm no great fan of object hierarchies (nor am I very good at them); I was just pointing out that it wasn't hard to come up with examples where the base classes were more generic and complicated than the specific instances that derived from them.
        --
        Ytrew
[reply]

In Section Meditations