In my application at the moment I have (as in so many other applications) an entity called Contact
, which represents any person. At its most basic level this is used to represent business contacts. However it can also be used to represent employees of the company. and there are also a couple of special types of employee (let say there is one called Manager
)
I am attempting to model this as an inheritance relationship which makes sense. Employees have names and addresses just like contacts, as well as a number of employment related attributes. Managers also have a number of manager specific attributes.
The difficulty comes when an employee gets promoted to a manager. Is it ok to convert the base class Employee
to the inheriting class Manager
? It feels wrong. I guess I would do it with a specialised constructor on Manager
.
As an aside does NHibernate support this kind of behaviour? is it as simple as getting the employee, creating the manager from the employee, then saving the manager?
Yes. We can always convert ( Cast ) a superclass reference into a subclass reference.
In java object typecasting one object reference can be type cast into another object reference. The cast can be to its own class type or to one of its subclass or superclass types or interfaces.
A subclass inherits from a superclass. A child class inherits from a parent class. A derived class inherits from a base class.
When we create an instance of a base class, its data members are allocated in memory, but of course data members of inherited classes are not allocated. So, downcasting from a base to a derived class is not possible because data members of the inherited class are not allocated.
I'd go with composition over inheritance in this case. If you stick with inheritance, you'll be changing classes with every promotion or demotion and every time you hire a contact or an employee leaves and becomes a regular Contact.
It's easier just to say Contacts have Roles. You can add a Manager Role to a contact to promote it and remove the Role to fire it.
As long as your business model matches your domain, you're doing the right thing.
However, it sounds to me like you should have something like:
Manager Promote(Employee employee)
{
var manager = new Manager();
//promote your employee to a manager here
return manager;
}
inside some workflow process of some sort.
In regards to NHibernate, it sounds like you're mixing your ORM logic with your business domain. Promoting an Employee to a Manager is a business domain construct, and as such belongs in your business model. However, how NHibernate maps your Employees and your Managers into your DB has nothing to do with your business model, except for how to map them over. This definitely doesn't have anything to do with how to promote an employee to a manager, though.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With