Polymorphic Domain Objects Based On Data Mapper

Question

I have a basic domain object, say like Person or Campaign or Event that is represented by a single table in the database. However, I also have more complicated versions of these objects say like a PersonCampaign or PersonEvent or even CampaignEvent that could theoretically extend one of the base objects.

However, for a number of reasons this becomes complicated because PHP does not support multiple inheritance (for example does PersonEvent extend Person or Event). And also because some domain objects are actually factory objects with varying properties and functionality (for example Event is actually subclassed by the type of event like email, call, fax).

The easiest solution that I can see is to have the actual nature of the object change based on what data is returned from the data access layer.

Does anyone have any suggestions on a better way to handle this? Or is it correct to create unified domain objects that can change properties and behavior based on what is currently available to it from the data access layer?

Answer 1

What about having a setup like:

Table: Person , Sales Person, Customer Person, etc.. The person table stores the generic information about all sub-types of persons. Then there are other tables FK'd to the person table. It stores additional unique information about that sub-type.

Your objects would either extend, or call the generic 'person' object to access primary data, then call it's unique type object to get access the unique data for that sub-type?

Answer 2

A solution is the encapsulate the other objects:

The PersonEvent class contains a Person and an Event.

Accessable by either a function $PersonEvent->get_event() or property $PersonEvent->Event;

Answer 3

From a OOP perspective a PersonEvent isn't really a object, its a relation.

The Person class could get functions like:

get_events()
add_event($Event)
remove_event($Event)

and the Event class

get_person()
set_person($Person)
unset_person() // set person_id to NULL

(Assuming a 1:N relation between person and event)

The bad part is, this will complicate the data-mapper or wont use the data-mapper at all.