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.