Hi Itai,
"Itai" == Itai Tavor <itai@optusnet.com.au> 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 situation. 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 ) or 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... or (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 itself. 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. -steve (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.)