On Aug 20, 2011, at 10:43 PM, Ken Anderson wrote:
> 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".
Ah. Yes. Good point. I meant get rid of Inheritance on Contact. The roles
themselves can make use of inheritance, or an even better way is for them to be
individual Classes, but use interfaces to enforce what behaviors they each must
have. Then you can have multiple interfaces associated with each role.
> 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
>>> jo...@netsense.nl
>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>
>>> This email sent to webobje...@avendasora.com
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
>>
>> This email sent to kenli...@anderhome.com
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
