Zope design: the liberal use of subclassing?
One component of our budding academic site is a searchable database of publications authored by department members. Publications come in various flavours: journal articles, conference proceedings, books, book chapters, etc. All of these share certain properties while others are unique. Question: In terms of ZClasses, is it best to create an abstract Publication ZClass with common data and methods and then subclass the various flavours? In addition to publication details, I also want the option of encapsulating the data files, be it in PDF, MSWord, ASCII, TeX format, etc. Question: Rather than create a slew of File-like products in the root Product folder, should I again create an abstract class and subclass for each Mime type a la the PDF example used in: http://www.zope.org/Members/lstaffor/zProperties 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). Summary Question: Generally speaking, rather than create a slew of ZClasses in the root Product folder, should one liberally subclass? Advice on these critical design decisions is most appreciated. Darran.
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.
participants (2)
-
Darran Edmundson -
Phillip J. Eby