Phillip J. Eby wrote:
>At 05:19 PM 11/1/00 +1100, Itai Tavor wrote:
>>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
>A class diagram contains all the roles - they're the lines between the
That's a great statement :) It really helps me decipher my object model.
>Look at it this way... if an object has a particular association role that
>it needs filled, and there is more than one kind of object that can fill
>that role, then presumably those objects must all implement a certain
>interface, right? You need to create a Specialist for that interface.
>In other words, there is usually one Specialist per collaboration interface
>-- which is NOT a one-to-one mapping with classes, since some classes may
>implement multiple interfaces, and some classes may all implement the same
How do you decide where to create collaboration Specialists? You
wouldn't have one for every line in the object model, right? Do you
use one only where there is more than one kind of object that can
fill a role? How do you determine if a collaboration interface
requires a collaboration Specialist, or can be done with a direct
connection between the two class Specialists?
For example, take an OrderLineItem object and a ShipmentLineItem
object (one describes a quantity of a certain product added to an
order, and the other that quantity of product being shipped). In the
interface between OrderLineItem and ShipmentLineItem, an OrderLine
can be seen as filling the role "thing that is shipped".
OrderLineItem also fills the role "thing that is purchased" when it
is added to an order. Would you create Specialists for each of these
Or, in the case of BillableEntities below, would you still use this
Specialist if there were only Customers in the system (so, only one
participant filling the "thing that places orders" role)?
Are collaboration Specialists only used to interface participant-type objects?
> >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.
>What *role* do Customer and Reseller objects play in your system? It
>sounds to me like perhaps they play the role of "thing that places orders"
>or "thing that orders are shipped to". Depending on your application's
>functions, you could need as many as FOUR specialists:
>Where the latter two specialists would contain a pair of Racks that mapped
>back to the Customers and Resellers specialists, respectively.
The collaboration Specialist won't actually *do* anything, would
they? They would only abstract the retrieval of participant objects,
so that any object which requires a "ship_to" property will not have
to know or care what kind of participant is referred to. Am I getting
this right? (Of course, I could add PD methods to
ShippingDestinations if I wanted to, like printShippingLabel, but in
a basic application this Specialist doesn't seem to need to do
anything at all).
Also, these collaboration Specialists seem to serve to hide the fact
that there are two types of participants. So, for example, a Payment
object would just know "things that get billed". So how would I ask
the Payments Specialist for "all payments made to resellers"?
> >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
>Huh? What do you mean by "methods that are specific to one payment type"
>in this context? What do payments do that requires knowledge of the rest
>of the application? If it's a problem-domain method, it belongs in the
Ok, I get this now. This question was based on my lack of
understanding of how a ZPatterns application is structured.
A Payment object needs to access other parts of the application - for
example, to get a UI snippet from BillableEntities. I thought that
ZClasses are supposed to be self-contained, without links to the rest
of the app, while methods that link parts of the app together belong
in the Specialists. I can see I was totally wrong in this.
>Please note, however, that at this stage of design you shouldn't be looking
>at how the references are going to be stored. At the abstract design
>stage, you would just have "Payor" and "Payee" attributes that are the
>actual related objects. When you write your SkinScript later, you can set
>up how the linkages work, using ID fields, or SQL columns, or whatever.
The reason I'm thinking about implementation now is that, this being
my first ZPatterns project, I want to make sure my design is actually
implementable. So I keep jumping forward and trying to implement
pieces of the design to see how they actually work.
This is a quote from a previous answer you gave to a question:
>...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.
This raises an implementation question: The UI for adding an
OrderItem is implemented in the Specialist, right? What if OrderItems
has two Racks - Item (for standard items) and CouponItem, each
requiring a different 'add' form? Would you place the 'add' UI code
for each one in the Rack? Or use a single UI method that customizes
itself based on the type of object being added?
One last thing - I just want to say I really appreciate all your help
(and that of other people who've answered my recent questions) - I'm
trying learn both formal object model design and ZPatterns at the
same time, and it's a slow and frustrating process - for me, but also
I'm sure to people trying to deal with my questions. Thanks!
Itai Tavor "Je sautille, donc je suis."
C3Works [EMAIL PROTECTED] - Kermit the Frog
"If you haven't got your health, you haven't got anything"
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -