Should I have a class EmployeeType since it is a entity in my db model?
I am avoiding to have a class so I will add Employee subclasses as we need another employee type. However, that will change my class diagram and will add some NEW code.
The relational <-> object mapping is rarely one-to-one.
Employee type can simply be a property of the class and nothing more - as long as that type does not affect behavior. You will have to add new code anyway once the type has an affect on object behavior.
I would not be surprised to see a bunch of code-value lookups in a system. A lookup API might let you look up one code to get a value to display for a given employee or a collection of all codes & values to put into a drop-down list. With that in place you wouldn't need an EmployeeType class. You might see:
A more specific thing to think about ... You're building a class hierarchy where some kind of role-based permissioning or behavior might be better. For example, if you promote a Clerk to a Manager you can't change the type of an object in memory from Clerk to Manager. But you could change it's permissions or behavior:
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: Nov 10, 2002
Thanks you guys for your help/references, this is and excellent starting point.