Thanks for all the comments.
It seems I have to rewrite the first part of my introductory WO-tutorial on
creating a webobjects app, in which I did a vertical inheritance with
subclasses of the contacts.
On 21 aug. 2011, at 00:04, David Avendasora wrote:
>
> 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
>>>> [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]
>>
>
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/archive%40mail-archive.com
This email sent to [email protected]
