David,
When you say have a Relationship to the abstract Role class, I'm assuming
you're recommending inheritance here. I do it the exact same way, just wanted
to make sure it's not confusing to say "do abstract this" and also "get rid of
inheritance".
For me, I have this type of structure in a few places. In one of them, the
subclasses of Role use single table inheritance, since the subclasses all have
similar data, but the methods are different. For another, I use horizontal,
since the data structures vary significantly. Thankfully, there aren't
thousands of objects, so performance is not a problem here.
Johan, you can always implement something in your Contact class like:
- (boolean) isActor {
// check to see if the to-one (or to-many) role(s) relationship has an
instance of the Actor role
}
or something like this:
- (ActorRole *) actorRole {
// find actor role in relationship or return null
}
to see if the contact fits the bill for a particular situation or not.
Personally, I always make the role relationship to-many, so that someone can
have multiple roles (will ALWAYS happen IMHO).
Ken
On Aug 20, 2011, at 6:33 AM, David Avendasora wrote:
> I've been there, Johan. Don't use inheritance. That's what is messing with
> you. An EO can't switch from being one Class to another. It completely er...
> um... screws with EOF.
>
> Get rid of the inheritance. Just have a Contact class that has a relationship
> to the abstract Role class, and make all the the roles subclasses of Role.
> You can change a contacts behaviors by setting the role relationship to an
> instance of one of the subclasses on-the-fly, however you want. Each subclass
> of Role can implement the various behaviors in their own way.
>
> The trick is that when you want a contact to behave as an actor, you set the
> role relationship to an instance of actor then call
> contact.role.assignUnderstudy(contact).
>
> Wait, you say, it is completely invalid to take a role
> nicepersontoalwayinviteforfreetoanyshow and say
> contact.role.assgnUnderstudy(contact)! well, the
> NicePersonToAlwaysInviteForFreeToAnyShow class has an empty implementation of
> the assgnUnderstudy(contact) method, or one that throws an error that the UI
> catches to tell the user that they are a daft git for doing something stupid
> as trying to give a nicepersontoalwayinviteforfreetoanyshow an understudy.
> Shesh. Everyone knows they can only be assigned AS understudies.
>
> That's the basics. Just get rid of Inheritance. Especially Vertical
> Inheritance (sorry Lachlan).
>
> Dave
>
> On Aug 20, 2011, at 4:58 PM, Johan Henselmans wrote:
>
>>
>> On 20 aug. 2011, at 01:26, Chuck Hill wrote:
>>
>>>
>>> On 2011-08-19, at 2:46 PM, Johan Henselmans wrote:
>>>
>>>> My idea:
>>>>
>>>> I have an entity contact, that gets vertically inherited into actor,
>>>> employee, visitor, nicepersontoalwayinviteforfreetoanyshow, whatever,
>>>> based on the role somebody/thing plays.
>>>>
>>>> A contact can have different roles, which makes this contact playing
>>>> actor, employee, visitor, nicepersontoalwayinviteforfreetoanyshow or
>>>> whatever. So there is a m-n relation roles in a contact.
>>>
>>> Where is Kieran? This is his favourite question. It sounds like you
>>> should be using the Role pattern and not inheritance.
>>> http://objectdiscovery.com/solutions/publications/roles/index.html
>>>
>>>
>>
>> I thought I used a Role pattern. situation:
>> base class is contact, others are inheritances all in the same table
>> contact - visitor
>> -actor
>> -director
>> -nice person
>>
>> role class - (defined via eo)
>>
>> contact<->role m:n
>>
>> I would assume that figure 13 in the article would be the most desirable
>> solution, as the role definition is dynamic (roles can be added)
>>
>>
>> <figure-13.gif>
>>
>> but I do not get how in that situation the specific methods and data of a
>> specific role would then be defined. Or perhaps I miss the point?
>>
>> For instance, and actor can have a relationship to a specific show, a
>> theatergroup, a paycheck, a visitor can have visited a specific performance,
>> etc. Where would you define that kind of behavior?
>>
>>
>>
>>>
>>>> I assumed that I should be able to create and get a visitor if I could
>>>> describe in the EOModel qualifier something like roles.ROLE.name =
>>>> 'visitor'
>>>>
>>>> Something like this:
>>>> <PastedGraphic-3.png>
>>>> And I would create the relation to the role in the awakeFromInsertion
>>>> phase of the Visitor.
>>>>
>>>> Of course this is not working, (nothing ever works where I live) as I am
>>>> getting
>>>>
>>>> takeValueForKey(): attempt to assign value to unknown key:
>>>> 'roles.ROLE.name'. This class does not have an instance variable of the
>>>> name roles.ROLE.name
>>>>
>>>>
>>>> What is the proper incantation to do this?
>>>
>>> I think that is not possible. The restricting qualifier has to be
>>> evaluated on that single entity only.
>>>
>>> Chuck
>>>
>>> --
>>> Chuck Hill Senior Consultant / VP Development
>>>
>>> Practical WebObjects - for developers who want to increase their overall
>>> knowledge of WebObjects or who are trying to solve specific problems.
>>> http://www.global-village.net/products/practical_webobjects
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> Johan Henselmans
>> [email protected]
>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>
>> This email sent to [email protected]
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
