One instance for two child objects

tchimev posted on Tuesday, April 28, 2009

I have a business base object with children like this:

-- MasterBB
---- ChildBB(Manager)
---- ChildBB
--------- ChildBB(Employee)

Manager and Employee can be the same or diffrent person.
When Manager and Employee have the same values could they reference the same object or they must be two different instances.
If they can be one instance, how should I implement it?

RockfordLhotka replied on Tuesday, April 28, 2009

Objects should be defined by behavior, not data.

You haven't provided enough information about your scenario to provide any meaningful advice.

It is very likely that within your use case that there are different behaviors between a manager and an employee even if they have similar properties. But that is just speculation on my part.

tchimev replied on Tuesday, April 28, 2009

It is my mistake.

My business object design is like this:

-- MasterBB
----- ChildBB (Employee)
----- ChildBB
---------- ChildBB (Employee)

Manager and Employee from the first design are the same business object, they have the same behavior.
They can reference different employee objects in memory, and sometimes can reference the same object.

RockfordLhotka replied on Tuesday, April 28, 2009

Again, I don't know your use case (a description of the task the user is trying to accomplish).

But it is uncommon for an object to reference the same type. It can happen, but it is not common.

The reason is that it doesn't usually make sense in the real world.

A doctor might do work on another doctor:

Doctor
  - ListOfPatients
    - Doctor

But really that makes no sense, because the second Doctor is actually a Patient. The fact that the patient is also a doctor doesn't matter for the use case, and so this wouldn't happen.

In fact, this doesn't even make sense usually:

Doctor
  - ListOfPatients
    - Patient

The reason is that a Patient is probably a root concept. What we really have here is that a doctor has a list of PastPatients or CurrentPatients or something like that. The child object in this case is almost certainly not the root "Patient" object from the edit a patient use case. The child object in this case is probably responsible for establish relationship between doctor and patient:

Doctor
  - ListOfPatientRelationships
    - PatientRelationship

This is far more likely to be something that would come from a use case.

IsValid replied on Tuesday, April 28, 2009

This kinda looks like a case where roles come in to play. Managers and 'managed employees' are basically 'Employees'. Based on the role that the Employee has been assigned, (s)he will perform actions within the system... If you look at it this way, then you have just one class, Employee; and you need to set authorization rules for two roles, viz., Manager and, say, TeamMember.

Mebbe, I am looking at things in too simplified a manner...

tchimev replied on Tuesday, April 28, 2009

Here is one simple use case:

I have a warehouse.
Each new article has to pass two checks before it is added to the warehouse.
Each check is performed by an employee.
Usually employee1 performs check 1 and employee2 performs check 2.
Sometimes one employee can perform both check 1 and check 2.

-- DocumentForArticleApproval
------ FirstCheckBy(Employee, ID = 5)
------ SecondCheckBy(Employee, ID = 5)

Should I use the same business object for the two employees?
Or should I design my objects to avoid this?

IsValid replied on Tuesday, April 28, 2009

This certainly reads like this: one class. Employee has two operations, FirstCheck and SecondCheck.

 

tchimev replied on Wednesday, April 29, 2009

@IsValid,
I do not understand the employee design, could you explain.

Any other suggestions would be appreciated.