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
posted 13 years ago
Thanks you guys for your help/references, this is and excellent starting point.
Forget this weirdo. You guys wanna see something really neat? I just have to take off my shoe .... (hint: it's a tiny ad)