Great! Excellent! Thank you Phillip for a good explanation. I guess you should write something like this for the ZPatterns Wiki. One more thing we still need is a set of 'right hand' rules. Let me try to formalize ZPatterns-based design process. 1. Write scenario (client comes to skydiving office blah blah blah...) 2. Detect roles learning scenario (Orders, Planes, Students etc) 3. Create an empty (blackbox) Specialist for each role 4. Populate the specialists with methods implementing roles 5. Create (whitebox) specialists implementing scenario Thus, the object classes (Customer, Order) went nowhere. The things ruled by black specialists are just identity markers, without methods, types and names. That's right? Or is the object an specialist specific internal abstraction which never leaves specialist's frames and have methods and type just for specialist's fun? "Phillip J. Eby" wrote:
First, I'm going to create some ZClasses, and specialists to go with them: SkyDiver, Pilot, Airplane, FlightManifest, RentalTicket, RentalItem (w/subclass for Parachute, Helmet, and certain other specific items). Then I'm going to set up the Resources and Products specialists to access my own specialists for these ZClasses. (Notice that I am going in and directly
How you will set up those specialists? By adding get(Resources|Products)Specialist methods?
that a Party plays in a resource scheduling system. SkyDiver, then should implement a Party interface, allowing it to be *used as* a Customer or ResourceUser. Thus, SkyDiver can be used by *any* framework that needs to collaborate with a Party object, although it may have a new *role* in which the party will be used. For example, if I later add a curriculum management system to cover my skydiver training courses, I will want SkyDiver to fill the Student role.
Well, we have two specialists, implementing roles (again, who _actually_ implements the role, specialist or class, CustomerSpecialist or Customer?). Now, "SkyDiver ... *used as*" means we should: 1. subclass (not a good choice) 2. implement interface 2.1. by copying and pasting methods code (or whole methoids) 2.2. by proxiyng (SkyDiver has a references to actual Customer and ResourceUser) 2.3. by transmitting messages to SkyDiverSpecialist which will pass unhandled messages to CustomerSpecialist and ResourceUserSpecialist (this is a variant of 2.2. case) The 2.3. case means we should use objects without types (identity markers).
I will also make some changes to each of these specialists to replace certain common UI snippets to be relevant to the kinds of things I'm dealing with. For example, in the Customers and ResourceUsers Specialists, I will replace the findForm method (if that's what it's called) to be a call to SkyDivers.findForm - a form that searches for skydivers by their ratings, certification, or freefall style, as well as name or phone number.
How about Editor and Renderer plug-ins for each specialist?
lifting" machinery and plug it into their local specialists, then gut the collaborator specialist and wire it to the appropriate local specialist.
If I understand something at all, whitebox specialist (Script?) called SkyDiverSpecialist must have its own data source (rack) for SkyDiver class and use 2.2. strategy mentioned above. (I just see no other way). Thanks again, Mike