Johan Carlsson wrote:
A Specialist manages objects that play a particular role in your application. You will usually have one Specialist for each role in your application; try listing all the roles, and what they do, and that's a good start for thinking about what specialists you need.
I'm a bit confused in regard to the roles. What exactly is a role in this context?
At first I thought of a rola as "a role of an Actor", but as you described it it's more like the role of the class (GoPlayers)?
I need to be really really pedantic and picky about terminology here, or else I think we'll get terribly lost! :-) "GoPlayers" is the name of a Specialist. There is a class called "GoPlayer". The class defines what properties/attributes a GoPlayer object may have, and what services it provides to the rest of the application. The class plays the role "definition of object metadata". The class defines one or more roles that GoPlayer objects play. Each instance of the class GoPlayer is an object. We can call such an object "a GoPlayer". However, GoPlayer is an abstract class; it really only defines the essential features that make up the most generic GoPlayer. However, any object that derives part of its behaviour and interface from the class GoPlayer can be treated like a GoPlayer by the rest of the application. So, a ProfessionalGoPlayer is treated like a GoPlayer. An AmateurGoPlayer is treated like a GoPlayer, also. I can imagine a class that derives from BankManager and also from AmateurGoPlayer, called GoPlayingBankManager. An object of that class plays the role of GoPlayer (under certain circumstances), and can be treated as a GoPlayer by the rest of the application. When you're thinking about a system, it is often helpful to think about just a part of the system rather than the system as a whole. To do this, you define a limited "scope" around a particular subsystem. In this case, an Actor represents the role something from outside your subsystem plays when interacting with something inside your subsystem. The "something" can be an object, a person, a separate computer system, a corporation...
How should I look at roles in ZPatterns?
This is all standard object-oriented stuff, and is not specific to ZPatterns. Get the Coad book, read it, and things should get clearer :-) Also, the Catalysis method puts an emphasis on defining interactions and collaborations between objects in terms of roles. You might want to take a look at that. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net