At 06:19 PM 11/29/00 +1100, Itai Tavor wrote:

Hi,

I'm trying to figure out the right way to implement a set of classes and roles in ZPatterns. I asked some questions about this a while ago, and then went away and did some learning, but I'm stuck again and I'm afraid I need to ask more questions.

I have two types of actors - Person (with properties name, phone, email, password) and Organization (with properties name, phone, fax, business_number).

I also have two participants - Customer and Reseller. Each participant can be either a Person or an Organization.

The participants can fill several roles, like OrderingEntities, BillableEntities, etc.

Starting from the bottom, I create a Specialist for each role, each one with two virtual Racks - customerRack and ResellerRack, so I can refer to an OrderingEntity without caring if it's a Reseller or Customer.

My problem is in implementing the Participant Specialists and storing Participant and Actor classes. Do I create Specialists for the Actors? It seems to me that since there is either one Person or one Organization per Customer, then the actor object should be created in the Customers Specialist. So Customers will have 3 Racks - defaultRack (using Customer object), personRack (using Person object) and organizationRack (using Organization object). Does this make sense?

I think what you want is to have an Actors specialist containing a personRack and organizationRack. That is, treat "Actor" as a role relative to either Customer or Reseller. The reason I say, "I think", is because I'm really not clear on why you're doing certain things here to start with. See below.

If this is a good way to do it, how do I handle creating and accessing the Person and Organization objects? Do I call personRack.newItem(newCustomerId) in the script that creates the customer? Or do I somehow do it in a SkinScript in defaultRack? And how do I get to the Person data? With an attribute provider? Or in

Here's a red flag: why are you creating a person when you create a customer? If a person is something that you only make when you have a customer, then the actor-participant-transaction pattern isn't really valid, IMHO. For Actor-Participant-Transaction to make sense, you have to have Actors that exist seperate from the Participants. While it makes sense to be able to create an Actor at the same time, your model needs to also include a way to select an *existing* Actor as the Participant, otherwise you are not gaining anything from the A-P-T pattern and you might as well just have the Participant. Here's a pattern for mapping A-P-T interactions onto ZPatterns, however... If you are doing A-P-T, make sure you use a Specialist for access to the Actors. For example, in some applications Ty and I write, "acl_users" is designated as the Specialist for actors if all actors in the system have to be able to use the application. The user interface and implementation for creating and/or selecting actors to fill a participant role is placed in the actors' specialist - acl_users in our case, or perhaps a specialist called "Actors" in yours. (But I'd recommend you use a domain-specific name, if possible.) So you would not be worrying about whether to create a person or organization or what fields they need or anything else in the specialist for your "participant" objects. Indeed, you wouldn't be worrying about whether a new one was being created, or an old one selected, if you delegate that aspect of the UI to the actors' Specialist.

Also, if Actors are stored in the Specialists that implement the roles they participate as, there is no place to store methods that are common to an Actor regardless of role - for example, a method that checks if a password is secure enough and called when adding a Person object. So I either duplicate these methods in every Participant Specialist, or create more Specialists - which seems like a waste either way.

Again, this is solved by using a specialist for the role "Actor".

Another problem is how to edit these objects - if I have a form which includes fields for a Customer properties and for the properties of the Person object linked to that Customer, can I change the Person object from the Customer SkinScript? I don't think I can do this:

WHEN OBJECT CHANGED STORE name, password USING

personObject.propertysheets.manage_changeProperties(name=self.name, password=self.password)

Right? Because name and password are not properties on the Customer DataSkin. So I have to call person.manage_changeProperties(...) in the method that changes Customer... it seems to me that I always end up doing object connections work in methods and the SkinScript can't help with anything :(

You're making this entirely too hard. The Prime Directive of ZPatterns design is, "if it looks too complicated in any one place, your design is probably wrong. If almost every individual piece looks simple, even though the whole is quite complex, your design is just right." :) Specifically, what you're doing here is trying to know things your object can't know. That's what delegation is for. You can't "edit" a participant and change data about the actor. That's an encapsulation violation. You can solve this several ways. In most of the app design I've done, I seperate editing the actor from editing the participant, simply placing a link on the participant object that references the actor directly, so that you can go and do whatever you need on the actor. However, that's not the only way to do it. You can always specify in your design that objects playing the actor role must have a method to provide an editing sub-form, and another method to accept data provided from that sub-form. You can then embed the actor's editing screen inside your participants' editing screens and call the actor's update method from your participant's update method. Problem solved.

Hope this is not too convoluted...I'd really appreciate any help anyone can offer. The existing ZPatterns examples all deal with fairly straightforward situations, but it's the more complex class relationships where the bears and tigers are hiding :)

Yep. While lack of ZPatterns implementation-level documentation sucks, it's quite clear that the really big issue for ZPatterns developers is the shortage of information on designing applications for ZPatterns. Basically what happens now is that I personally tutor everybody, and there's a couple of people who are passing on what they've internalized enough to be able to teach others. Complex examples would be helpful, and perhaps sometime I'll take a look at mapping a couple of the projects in Peter Coad's book into ZPatterns models. Coad's book is key to learning how to divide up responsibilities between classes, and it's important to work through those seperations before you try to map to ZPatterns. I'm guessing you've read the book, but I think you might want to study it a bit more deeply, because your design as presented above has classes trying to do work that properly belongs to other classes. The key thing I learned from the Coad book was that O-O designs are always simple -- *after* you seperate responsibilities. As Ty and I worked on designs, we came to realize that apparent complexity was always a clue that we either didn't have as many classes as we needed, or we were giving classes jobs that belonged to other ones. The Law of Demeter for methods is also a very handy checkpoint. If your design will require you to violate it, that is a concrete signal of excessive complexity, poorly seperated responsibility, or the most egregious of O-O design sins: failure to create domain-specific methods. (Notice, for example, that Coad never gives collections generic access methods, but instead puts any behavior that requires knowledge of contents directly into the collection object itself. That is, he makes a domain-specific collection, and never uses a generic "collection" object.)