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

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to