OOP: Object Relationships

I’m trying to figure out how to setup some object relationships. Example…

A ‘company’ can have many ‘departments’. A department can have many ‘staff’. A member of staff may work across many different departments.

So… Initially I thought, the ‘company’ object creates and holds the ‘department’ objects, and the ‘department’ objects create and hold the ‘staff’ objects.

PROBLEM… As a staff member may appear in different departments, that means there could be two or more distinct ‘staff’ objects for one member of staff, held in different department objects. Now if one of those staff objects is updated, it leaves the other staff object (in the other department) outdated.

The ideal situation would obviously be to have two (or more) department objects reference a single staff object - so there’s no object duplication.

What’s the best way to do this?

  1. Have the company object create both the ‘staff’ and ‘department’ objects and then have it “add” the staff object references to each department? This seems like the most logical solution in a lot of ways. However, it seems a bit silly that the department object can’t create its own staff objects. And it also makes the objects highly dependent on each other?

  2. Use the “registry” design pattern that would hold staff objects? Hmm not sure about this one, the registry design pattern. Seems a bit “global” with all the potential dangers that come along with that.

  3. Something else?! :slight_smile:

Please let me know what you would do. I’m sure there’s a simple solution to this. But I can’t think of one that isn’t long-winded. I would really appreciate your expert opinion!

The relational pattern of objects in a database does not have to match those of the PHP objects that retrieve their data. In my experience they rarely do. For example, in the model section of my code you have a basic table object that can be extended. In its use it creates row objects which in turn create field objects. Now those field objects have a inheritance pattern - abstract field, specific field (say text), more specific (say, email address) that build on each other.

These relationships have nothing to do with the database entity relationships. Again drawing from my current project - I have a personal table for personal information. It is a parent to the address and phone table. But wait, the address and phone table also have companies as a parent. These relationships however aren’t reflected in PHP - all these tables are managed by the same table class.

Thanks Michael. However, I’m not really sure what you’re suggesting.

I understand that database relationships don’t always match object relationships. However, in my example, I think they probably should?

Company, department and staff objects have enough distinct properties and functionality to warrant and benefit from keeping them as separate objects?

I’m probably missing the point. If so, could you provide an example that relates directly to mine?

I went back and reread your post. I think what would help is don’t confuse instatiated object relations with class relations.

For example, if your staff, company and department objects share common methods perhaps they should decent from and entity class or abstract.

Once instatiated each object can hold references to any number of other objects. For example a department object can hold references to all it’s staff objects, each staff object can reference it’s department objects.

Multiple inheritance in this case isn’t a problem since the classes aren’t inheriting.

That’s probably clear as mud but I’m sick today so maybe I should come back to the thread when I have a clearer head less muddled with dayquil.

The staff, department and company objects don’t really share any common methods or properties. So I don’t think they would stem or inherit from the same class. I’m still not really clear how it would solve the problem anyway to be honest (I’m probably missing it!).

The key problem is that two or more staff objects might exist for a single member of staff. So an update to one of the staff objects would make the other outdated.

I think the key is in referencing only a single staff object for a single member of staff. So the departments (that the staff member works in) all hold a reference to that single staff object. The question is, how to do that across several distinct department objects that have no contextual knowledge of each other.

Get well soon :wink:

In SQL, a solution would be to have 3 tables:

Department: (id | name)
1 | Human Resources
2 | Accounting
3 | R&D

Employee: (id | name)
1 | John
2 | Mary
3 | James
4 | Bob

Employees_Department (Employee_Id | Department_id)
1 | 1
2 | 1
3 | 2
3 | 3
4 | 3

That’s exactly what I have for the database schema. That’s not the problem. But thanks anyway.

It’s structuring the PHP object relationships that’s the problem.

I think I’m going to use the registry design pattern, unless anyone can give me a reason not to. It seems suitable.