[Zope] Zope design: the liberal use of subclassing?

Phillip J. Eby pje@telecommunity.com
Tue, 18 Jan 2000 12:09:12 -0500


At 05:16 PM 1/18/00 +1100, Darran Edmundson wrote:
>
>The same applies for People, variants of which 
>include staff, students, alumni, visitors, etc.,
>with the difference that people can migrate from one
>class to another (student to alumni).

Class transformation is generally a bad idea; you probably want both a
Person object *and* another object representing their role or state in
another process; i.e. an "Actor-Participant" pattern.  When the state or
role changes, you just switch out the referenced "participant" object.  In
your case, you have a Person object which can have a Staff, Student,
Alumnus, and/or Visitor object as a property (possibly multi-valued).  The
person would delegate various methods to the state objects involved.  If
you don't take this approach, you will have the problem of having to get
rid of an object and create a new one every time you have a state change,
plus a fixup of the object references.

Here's a possible set of classes:

Student - has fields for GPA, Major, etc...
Alumnus - has fields for graduation date, honors, contributions...
Staff - has fields for specialty, salary, hire date...

Each of these could derive from an "Association" class which contains
begin/end dates and a status field indicating whether the relationship is
currently active.  Thus, a collection of Association objects under the
person would give you their employment and/or scholastic history.  The
collection of people could be a user folder, and you could override
__ac_local_roles__ to return roles based on their active Association objects.

Of course, all this may be (i.e. probably is) way overkill for your
application at the present time; I'm just pointing them out 'cause I'm
involved in a large system modelling project in which application of these
patterns is paramount for model scalability, code reuse, and faithfulness
of the model to the items being modelled.

I'm actually mixing two patterns in my explanation: Peter Coad's
"actor-participant" as laid out in the book, "Object Models: Strategies,
Patterns, and Applications", and the "Business Patterns of Association
Objects" presented by Lorraine Boyd in the book, "Pattern Languages of
Program Design 3".  Both are useful works, but the Coad book is IMHO an
essential for designing an object model of any size; it takes the theory of
such things as the Law of Demeter and shows how to apply it in everyday
modelling issues.