I have one abstract class Employee with attributes - (Name, Address) method - Hire(). I have two child classes, HourlyEmployee with attribute - (Rate) and Salaried Employee with attribute - (Salary) So when I draw the class diagram, I have the two child classes pointing to the parent. Now, during implementation, we have layered the classes, i.e. we no more have the parent class. Instead we have 1. HourlyEmployee class containing only the attribute "Rate" and 2. Hourly EmployeeHandler class containing the method "Hire" and 3. SalariedEmployee class containing only the attribute "Salary" and 4. SalariedEmployeeHandler class containing the method "Hire" My question is how we can show relationships in such situations. Do we revert to the logical model or try to draw relationships on the existing relationship?
The model and code should always be synched. If you dropped the abstract super class from the code, drop it from the model also. If you ask me, I would've kept the abstract super class. Is there any particular reason for dropping it?
What was your motivation for the handler classes? What is the connection to the MVC pattern?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Employees like this are found in some examples in Robert Martin's Agile Software Development. He wound up with a single employee class with a variety of payment strategy objects. If a person is promoted from hourly to salary, can an employee object change class? Not in Java. But it can replace it's hourly payment strategy with a salary payment strategy. Look for Gang of Four Strategy pattern or maybe State pattern. Both delegate behavior to other objects when behavior can change over time. [ August 27, 2003: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 23, 2002
Now that Stan mentioned it, I think Fowler also used an Employee class hierarchy as an example in Refactoring.
Originally posted by Stan James: He wound up with a single employee class with a variety of payment strategy objects. If a person is promoted from hourly to salary, can an employee object change class? Not in Java. But it can replace it's hourly payment strategy with a salary payment strategy.
The Classifier Design Pattern would also be appropriate in this case. Regards, Fintan