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

[Itai Tavor]

Phillip J. Eby wrote:

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

Ok... I think I get the "Specialist per role, not per class" part. 
But I still can't make the jump from a class diagram to a 
ZClass/Specialist setup.

I can solve some of it by subclassing ZClasses. So, if I need 
Customers and Resellers, I'll make a Specialist for each, and a 
Customer and Reseller ZClasses, both subclassed from Person which 
stores common properties for a person. This part is ok. But it gets 
more complex than that. Take this example: Every OrderLineItem object 
can have one or more Payment objects associated with it. There are 3 
possible payment types - Check, Charge and BankDeposit, so I make a 
ZClass for each one, all subclassed from a general Payment ZClass. I 
create one Payments Specialist with 3 Racks. Where do I store methods 
that are specific to one payment type? In the Rack? I can't store 
them in the Specialist - it would be a mess, and I can't store them 
in the ZClass, because the ZClass doesn't know about the rest of the 
application. Actually, writing this down makes me realize that it 
could work... would Payments.getItem(some_payment_id).someMethod() 
call someMethod in the Rack if one exists, and the one in the 
Specialist if not? I guess that would make it very easy... 
subclassing moves into the Specialist.

Another problem I'm having is how to store id's for different objects 
in the the same field. In the Payments example above this is not a 
problem, because all payments are supplied by the Payments 
specialist. But what about another example - Customers and Resellers 
are two totally different roles, so they each get a Specialist. the 
Payment object has from_id and to_id fields, and each of those can 
hold the id of a customer or reseller, or some special code to 
indicate the store. I could add from_type and to_type fields, or I 
could prefix the id with a code letter, but neither seem like a good 
solution. Is there a recommended approach for solving this problem?


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

Thanks! I feel a little better now :)
-- 
Itai Tavor                    "Je sautille, donc je suis."
C3Works    itai@c3works.com              - Kermit the Frog

"If you haven't got your health, you haven't got anything"