On Nov 5, 6:27 am, Karl von Laudermann [email protected]
On Nov 4, 5:45 pm, Mike L. [email protected] wrote:
things in real life. For example, Rectangle should be a subclass of
Square, not the other way around. This is because the Square class
only needs one dimension member variable, e.g. “width”, and the
Rectangle subclass needs to add a second one, e.g. “height”.
The guiding principle is wrong. And it’s an egregious error I keep
seeing repeated. Lest a whole new generation of newbies follow this,
lets name the real principle involved in the design of superclasses:
abstraction based on common conceptual denominators, which in cs terms
means essential common datamembers and essential common behavior gets
aggregated to superclasses. This has NOTHING to do with # of
Repeating: Superclasses are based on common conceptual denominators
(CCD)not on the number of data members.
That in many-to-most cases there are fewer datamembers in the
superclass is true, but not the guiding principle. And classically one
uses the hierarchy to enforce certain constraints based on those CCDs.
Also the simplicity of the example gives false security – broadening
the problem in question regards general closed shapes. For example.
if I were designing this, the hierarchy in Ruby psuedocode, to capture
the essential nature of the shapes, you have to encode that nature of
a closed polygon which means closure, no self intercept for any
enclosed area by arbitrary points. THEN you encode regular polygon
behavior as sides of same length and then, if you need to, name
squares, pentagons, hexagons as regular polygons and rectangles and
similar as closed polygons.
Now purists will scream but “square ARE rectangles!”. Which is poor
thinking. The correct statement is “Squares and Rectangles are four-
sided closed shapes. Squares have equal sides, rectangles do not.”
As always, your model and its general power defines the flexibility
of your application. Ruby pseudocode for clarity below.
class RegularPolygon < ClosedPolygon
class Square < RegularPolygon
class Rectangle < ClosedPolygon # See!!! CCD’s properly
# Square from Rectangle on Essential
which allows of course the proper definitions of things like
class Pentagon < RegularPolygon
class IsoTriangle < ClosedPolygon
class EquiTriangle < RegularPolygon
which has little to do with datamembers (most are in the superclasses)
and all to do with the common conceptual denominators of abstraction
and where behavior is properly defined.
My best to all.