modeling possible polymorphism?  
Author Message
Elhanan





PostPosted: 2006-10-25 1:32:00 Top

java-programmer, modeling possible polymorphism? hi..

i have entity called AssuredPerson and entity called PolicyOwner, both
have similar attributes (meaning Abstract Person Class)

however an AssuredPerson can be PolicyOwner (but not the way around).

so i've added a property called isPolicyHolder (boolean) to
AssuredPerson.

is this correct way to go about it?

 
Manish Pandit





PostPosted: 2006-10-25 2:24:00 Top

java-programmer >> modeling possible polymorphism? Ideally, if the attributes are same, this seems more like 'has-a'
relationship. There is a Person who "has" a Policy. The qualification
of a person being "assured" depends on him "having a" valid policy. So,
the entities could be a Person and a Policy IMO.

-cheers,
Manish

 
Elhanan





PostPosted: 2006-10-25 16:26:00 Top

java-programmer >> modeling possible polymorphism? yes but it may be possible the PolicyHolder may have differen
attributes then AssuredPerson Attributes, it could be 2 different ppl
or the same person.

Manish Pandit wrote:
> Ideally, if the attributes are same, this seems more like 'has-a'
> relationship. There is a Person who "has" a Policy. The qualification
> of a person being "assured" depends on him "having a" valid policy. So,
> the entities could be a Person and a Policy IMO.
>
> -cheers,
> Manish

 
 
Tom Forsmo





PostPosted: 2006-10-29 19:37:00 Top

java-programmer >> modeling possible polymorphism?

Elhanan wrote:
> yes but it may be possible the PolicyHolder may have differen
> attributes then AssuredPerson Attributes, it could be 2 different ppl
> or the same person.

This is a dynamic role issue. so instead of modelling it as two
different person type classes, which have the well know limitation of a
person only being able to have one role/function, you should rather have
a person class with a "has-a" relationship to some role objects. This
allows you to combine persons/roles as you desire dynamically.

These role objects could then contain the specifics of that persons
role. This would support dynamic/run-time changes in a persons role. In
contrast to the static class model you originally proposed, which would
require changes to the code every time a new person/role relationship is
invented.

For a policy you would follow the same principle with regard to people
involved in the policy, e.g. say you needed to create a new policy where
there was a third participant in the policy, e.g. "PolicyGuardian".
With the dynamic version you only need to add the PolicyGuardian class
and a couple of methods to deal with that participant, and you are ready
to go.

tom

>
> Manish Pandit wrote:
>> Ideally, if the attributes are same, this seems more like 'has-a'
>> relationship. There is a Person who "has" a Policy. The qualification
>> of a person being "assured" depends on him "having a" valid policy. So,
>> the entities could be a Person and a Policy IMO.
>>
>> -cheers,
>> Manish
>