Re: Schema Design: Composition vs Subclassing

Roger,

You are great-- thanks for continuing the best practices work!

==

If->

> A couple of weeks ago I raised the topic: which approach is to be
> favored - design by subclassing or design by composition.  There were
> numerous responses, largely in favor of subclassing.

then->

> Since that time I have gone off and done some thinking and researched
> how this design issue is approached in the Object-Oriented field.  As a
> result I have now convinced myself that composition should be the
> favored approach (as it is in the OO field).

Hmmm, I am not sure I follow on this one : ). I think I am having trouble
identifying the direction from which this is approached. It seems (I could
be very wrong) that composition favors the user, whereas subclassing favors
the designer and the system (in terms of ease). For instance, suppose you
needed to add a similar element to every recording-medium (e.g.
number-of-pictures-allowed). This requires the Schema designer to change
three defintions within the schema because they are loosely coupled. In the
subclassing approach one definition could be changed (recording-medium) and
it would ultimately filter into the other three through the type heirarchy.

While I can accept the point that as type heirarchies become larger they
become difficult to understand-- I wonder how often the user needs to
understand them. In a perfect world the tools pop up a little window that
shows all of the allowable elements at a given point... etc. The restriction
point is a very good one-- but I wonder how many people are using
restriction-- were any of the responses arguing for restriction (other than
by default)?

Also, I noticed you were using a lot of AOSD terms (Aspect Oriented Software
Development) is this from the Design Patterns book?

Cheers,
Jeff Rafter
Defined Systems
http://www.defined.net
XML Development and Developer Web Hosting

Received on Monday, 15 April 2002 12:51:20 UTC