[Zope-dev] Questions about implementing object models with ZPatterns

[Phillip J. Eby]

At 12:35 PM 11/1/00 +1100, Itai Tavor wrote:
>Hi,
>
>How do I implement gen-spec classes using ZPatterns and ZClasses? 
>For example, I want to implement Person and Customer. Writing it in 
>Python, it would be easy to subclass Person to get Customer, and 
>Customer would inherit Person's properties and methods. If I instead 
>create a specialist and ZClass for each class, do I use a SkinScript 
>to remap Person's properties into Customer? And what about the 
>methods - Customer can't inherit Person's methods, so I have to write 
>methods in Customer which call the same methods in Person. This seems 
>terribly complicated... am I missing something?

If you want subclasses, just subclass ZClasses.  As for the remapping,
etc., it depends on what you want to do.  Keep in mind that Specialists are
created per *role* or *interface*, not per class.  You can have a "People"
specialist that has a personRack and a customerRack in it, for example.
Specialists are application- and usage-driven; you don't always end up
creating specialists for every class in your object model.

(By the way, note that if you have a personRack and customerRack in the
same specialist, they can share data plug-ins (such as SkinScript methods)
placed directly in the specialist.  The ranking order of the parent
plug-ins in the child racks is determined by where you place a "Link to
Parent Data Plug-Ins" in the racks' data plug-in lists.)


>Another question: In Coad's examples, if a class has an 'n' order 
>relationship to another class - say Order and OrderItems, Order would 
>contain a list of OrderItems. Each OrderItem would contain the id of 
>the Order it belongs to. It seems to me that it would be easier for 
>Order to call OrderItems.getItemsForOrder(self.id), then I don't have 
>to maintain a list in Orders, and if I add an OrderItem the Order 
>will immediately know about it without me having to call it and tell 
>it the OrderItem was added. Is there anything wrong with this 
>approach?

Nothing at all.  It's the recommended approach, actually.  This is how you
make frameworks work...  by delegating to specialists responsible for a
role in the application.  That is, instead of the Orders system having to
know anything about how order items are actually implemented, it can
delegate that function to an OrderItems specialist that could have such
things as DiscountItems, ReturnItems, and all sorts of other objects that
implement an OrderItem interface.  Similarly, rather than an Order
providing its own interface for entering an order item, the UI code can be
(should be) placed in the OrderItems specialist, and called by the Order
object's add/edit forms.

Encapsulation at its very best.  :)  That's the ZPatterns way; the tools
were specifically created to make it easy to do things the "right" way from
a seperation-of-powers standpoint.