This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
when 3 objects with same attributes but perform different operations be reprented as 3 distinct classes in the system or as a single class? Eg: Helpdesk System for internal use The 3 roles the employees of the company can play are EndUser,Technician and Admin All 3 can be represented as Employee in the database but these 3 can perform diferent operations based on the user type. If 3 classes namely EndUser,Technician and Administrator created in the System, the same set of attributes will be repeated in all 3 classes.
Could someone suggest a better way of modeling this scenario?Thankx in advance.
Without knowing anything else about your application it's hard to give a single "best" solution. However, you should probably consider at least:
Create a single Employee class (probably abstract) which contains all the shared attributes and behavior. Then use inheritance to create three thin classes of specialist employee with role-specific behaviour.
Create a single Employee class, which contains all the shared attributes and behaviour. Then create a separate base class or interface with methods for each behaviour which varies between roles. Pass in an instance of an appropriate role class when you create the Employee. Add methods to the base Employee class to delegate behaviour to the supplied role object.
From your description it appears that you are assuming each person will have only one role. This is a common assumption which can fail in practice. In many real-life situations, people hold multiple roles. So another solution might be to maintain a collection of role objects, or a Set of flags to indicate which roles are held by each employee. For each role-specific behaviour, loop through all the roles held by that employee and perform all the appropriate behaviour.
Originally posted by KHP Virajith: The 3 roles the employees of the company can play are EndUser,Technician and Admin All 3 can be represented as Employee in the database but these 3
If all 3 roles are to be played by an Employee entity then it definitely has certain attribute(s) which identifies its role in the system. In terms of a simple database design, you can have - 1. An Employee Table 2. A Role Table.
If an employee can play only one role at a time, you have a foreign key 'roleId' in employee table. If employee can have multiple roles at a time, then you can have a relationship table like 'EmployeeRole' which has both �employeeId� and �roleId�.
With respect to modelling, a class diagram could have 2 classes (Employee & Role) with an association between them that defines its multiplicity.
If the fields are really the same for all People and the behavior difference is just what they can and cannot do, that's getting close to a classic Access Control List. I've seen this several times as:
user has any number of roles role has any number of resources
Sometimes the "role has resource" is refined to "role has some or all of create read update delete execute access to resource". A couple times I've seen roles built up in a hierarchy, so roles can have roles. Most times the most restrictive path to the resource wins - if I'm a Manager I can do Manager things but if I'm a Manager and a Clerk, I cannot do Manager things.
Role and resource are just names of things, strings, nothing magical. For anything one user can do that another cannot we create a resource and give the appropriate users access through their roles.
I might model all that in UML, but I'd probably implement it in SQL.
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