In an example they give in the book, a role can be at the same time an
actor. So a Person (actor) can have a role as a TeamMember (role) - and a
particular TeamMember (actor / role) can act as a TeamLeader (role) - how
they map this out is that TeamLeader extends TeamMember extends Person.
Well, not quite... they make a distinction between class-based inheritance and object-based inheritance. Actor-Role is an object-based inheritance situation but most languages don't support that sort of inheritance - they only provide class-based inheritance. So you end up working around it by having an interface that represents the core attributes of the actor and the have the role implement the actor interface and use a data member to delegate most of the actor's implementation to. See Mike Abney's paper:
http://www.streamlinedmodeling.com/papers/object_inheritance.pdf
This highlights one of the biggest problems with OO languages today - they mostly provide an inheritance mechanism that doesn't really match how real-world inheritance works which means that we always have a bit of a disconnect between the relationships in the model and the way we implement them in the language. Hence a person which is an actor also "has-a" role - so we have to find ways within our implementation language to implement the subtleties of the real-world.
Nicola, Mayfield and Abney show that you can optimize certain common design patterns in certain situations by simplifying the relationships and 'unwinding' the is-a / has-a connections to provide more efficient (but less flexible) arrangements of classes. It's been one of my recommended books on architecture and design for some time:
http://www.corfield.org/index.php?fuseaction=bookstore.main
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
