I don't know if this helps or not, but i've been reading Streamlined Object Modeling and they've reduced a lot of patterns into a few basic building blocks, and one of them is actor - role. An actor can be a person or an organization, a role is something that an actor does in a particular context.
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. But the usual case is that an actor is simply extended by a single role, and an actor can of course participate in a system using multiple roles, or change roles over the course of time. The actor / role distinction helped clear something up for me, because i *think* our tendency would be to jump into the context - and try and work out the relationships between roles, leaving out the root object of the actor. I quote an earlier post from today, i'm just repeating here what i've read in books, but this particular thing made a lot of sense to me. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Sparrow-Hood, Walter > Sent: Tuesday, November 25, 2003 1:41 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] [follow-on] Using components > > > As a continuation of the discussion on user/role, I'm curious how people > would suggest I model the following relationships. > > I have a corporate portal with many applications that are accessed by > various groups( employees, contractors, distributors, etc.). Each group > (i.e. a database table) is composed of all possible members of the group, > i.e. all employees. Individual members of the group belong to > companies and > that is a 'has a' company relationship. Where I'm stuck is that > members can > register at the site and become registered users, i.e. users are > a subset of > members. However, registered users can belong to any of the groups. What > should the relationship be between users and members? Is it a user 'is a' > member? However, a user can belong to any group. Or, is it a member 'has > a' user profile? Thoughts? > > Walt > > -----Original Message----- > From: John Farrar [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2003 2:01 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Using components > > Thanks for answering Sean... that is part of why threaded > discussions can be > better... it's easier to follow the flow of a converstation... but the > tradeoff is you end up running out dozens of branches. Why isn't life > perfect? (there's another one not many of us would agree on.) > > John > > ----- Original Message ----- > From: "Sean A Corfield" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, November 24, 2003 1:01 PM > Subject: Re: [CFCDev] Using components > > > > On Nov 24, 2003, at 6:47 AM, John Farrar wrote: > > > Isn't "wrong" a bit harsh? > > > > That's why 'wrong' was in quotes - it's subjective. > > > > > Don't just tell us it is wrong if it is that big of an issue, give us > > > the skinny details! > > > > I gave some references - go read them :) > > > > > If another method is much better, then it ought to be > > > expressed that way. > > > > Design is all about trade-offs. Something that is "much better" in one > > situation might not be so in another situation. > > > > My point was that Nathan held something up as a "classic example" of > > inheritance but if you read what the OO gurus have to say about that > > example, you'll see that they specifically recommend not using > > inheritance (for the manager/user relationship). Therefore Nathan's > > example was 'wrong' in the sense that it is not a "classic example" of > > good inheritance. > > > > Part of the problem with encouraging good OO design is that there are > > so many examples of poor OO design - even in books (don't get me > > started on how poor many books are!). > > > > 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] > > > > ---------------------------------------------------------- > 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] > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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]
