Re: Schema Design: Composition vs Subclassing

Jeff Rafter wrote:
> 
> Roger,
> 
> You are great-- thanks for continuing the best practices work!

Thanks Jeff!  Good to hear from you.

> 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.

No, each recording-medium component (e.g., 35mm, disk, 3x5, IR, etc) are
in the substitution group with the abstract recording-medium element. 
Thus, their types are the same as, or derived from, the
recording-medium-type.  If we knew that number-of-pictures-allowed is
common to all recording-medium components then we could put that in the
recording-medium-type.

I am not advocating the ban of subclassing, just a ban on its overuse.

> 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. 

Good point.  From a user perspective, all the schema details may be
hidden.  I think the aspect of design-by-composition that is so
appealing is its simplicity and modifiability.  We can easily drop in
new components, replace components, etc.  We have reduced the coupling
within our schema, so we are able to morph it much easier.  Less schema
coupling = greater flexibility and long-term modifiability.  Thus, how
we design our schema is important.  The user may be hidden from the
details of the schema, but if the schema is to evolve (hopefully based
upon user inputs) then it must be designed in a simple, modifiable
fashion.

> 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)?

My observation is that people use both extension and restriction,
extensively.
> 
> Also, I noticed you were using a lot of AOSD terms (Aspect Oriented Software
> Development) is this from the Design Patterns book?

I am not familiar with AOSD.  The terminology that I used is that which
the Design Patterns book uses.

/Roger

Received on Tuesday, 16 April 2002 11:06:04 UTC