modeling possible polymorphism?

[Elhanan]

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]

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]

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.

 

[Tom Forsmo]

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