Teoman Haliloglu wrote: > Depending on the person's role(s), you have to know different stuff whereas > you have to take different actions to different events. > Which means you'll need to keep different data and methods for different roles
This is exactly the point. Once a person has data stored under the Contractor class, it is not the case that there is necessarily a place for all of it in the Employee class. > in addition to default data and default methods. Meaning those that pertain to any Person - yes, that is correct. > That would suggest keeping the roles as classes inherited from Person, am I wrong? Yes. > Also, even Cache documentation has the same example everywhere, that was > what encouraged me to go this way... But it assumes that you will never try to change an object's type. "Once an Employee, always an Employee." If a Person can be an Employee and a Patient, then Employee and Patient need to have a pointer to the Person instance, not be subclassed from it. That may not sound right. But in this model, the Person is the object. Employee and Patient are just various Roles that instance of Person can have. You could have an abstract class PersonRole that has pPersonID as Person and pRoleID as Role. Then Employee, Subcontractor, Volunteer, Patient, etc., could extend PersonRole. Each of those classes would contain the specific methods, properties, etc., that pertain to that subclass. > Because I only need employee specific data when he's my employee, when he > changes his role and goes back to being an ordinary person, I wouldn't care > about losing data. That depends. I can tell you that in the USA that would not be acceptable... nor for a Person who was a Patient or Customer. > (I do keep employment history data by the way) Well, where? Apparently not in Employee, so what is in Employee that isn't in Person? The answer is that you store all that employment history somewhere else, why not in Employee and just have Employee point to Person? > If he becomes my employee again, I will enter the specific data again > and save him as an employee. But what if he is a Volunteer or Patient simultaneously? What if he becomes a member of the SteeringCommittee or a Stockholder? > I think I can play with globals and subscripts for switching classes, but > looking for a better, object oriented way... At the level of abstraction you are describing, an Employee is *not* an object, but rather a temporary relationship between a permanent Person and your company. > Still, if you think switching objects between classes in time is not good > practice, what would you suggest? As I said before: > > Your situation suggests [to me] that you need Person and Role. So I suggest Person with Employee pointing to an instance of Person.
