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.