>>>>> "Itai" == Itai Tavor <[EMAIL PROTECTED]> writes:
Itai> I'm already using globally unique ids, but still, doesn't
Itai> using the same id for the Participant and the Actor make
Itai> these objects too tightly coupled? Seems to me that Actors
Itai> should provide an interface for finding actors to the rest
Itai> of the application; other objects should not make
Itai> assumptions about the internal storage of Actors, and
Itai> particularly what ids they use. No?
Well... there are two aspects here: 1) Who knows about how
various Participants and Actors are managed and 2) How are they actually
managed. Tight coupling is only about "1". It seems to me that "2" is
up to you as the developer to decide based on the particular
I'm sure that ZPatterns Zen is like most things... you learn by
getting your fingers burnt ;-). However it seems to me that it
should be OK for an Xs Specialist to implement
getXforY( y_id )
getXsforY( y_id )
(if there is more than one x for a single y.
If you have an XOR relationship, with several potential Specialists
I think you could either:
(A) iterate through the list of possible Specialists and ask each to
getXforY until you get a hit...
(B) have a 'clearing house' Participants specialist, with a Rack for each of the
Participant types and let it iterate through the racks and return
an object of the right type based on which one is a 'hit'. (Specialists
of course do this automatically!)
The advantage of (A) is, one less Specialist. The disadvantage is that
the Actor Specialist needs to 'know' about the list of Participant Specialists
The advantage of (B) is that the clearing house Specialist keeps track
of all the different Participants types... and the iteration is 'automatic'.
However... I think that either of these is 'OK' as far as coupling is
concerned. In both cases the information about the different types
of Participant is kept in a single centralized place [(A) in the
Actors Specialist] and [(B) in the clearing house Specialist]. *If*
you had some *other* Specialist that also needed to iterate through the
various types of Participants... *then* B would be a clear advantage,
and probably worth the added complexity.
Anyway.. just my random thoughts.
(P.S. it was refreshing to hear pje mention that he and Ty had to "bite the
bullet" and add new classes/Specialists on a project and only *after* that
it got much simpler, clearly implying that the original design was less
than perfect. It seems to us newbies sometimes that they possess
the Deific characteristic of near (object oriented) infallibility whereby
they produce clean, elegant, yet simple object oriented designs with the
same graceful ease with which they might compose a grocery list, while we
mortals struggle for hours and days to come up with something that they might
discard after a moment's thought. Anyway.... in the end we'll all learn the
most by hard experience, if only she were a more forgiving Mistress!)
(P.P.S. I still really like your idea of codifying some of these
ZPatterns techniques into a sort of gallery of ZPatterns Implementations.
I'm working already on incorporating some of these into the ToDo example.)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -