This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Model entity classes in the system Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Model entity classes in the system" Watch "Model entity classes in the system" New topic

Model entity classes in the system

Khp Virajith
Ranch Hand

Joined: May 01, 2006
Posts: 85
when 3 objects with same attributes but perform different operations be reprented as 3 distinct classes in the system or as a single class?
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.

Frank Carver

Joined: Jan 07, 1999
Posts: 6920
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.

Strategy Pattern (and possibly Template Method pattern)

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.

Multiple Roles

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.

Do any of these choices halp?

Read about me at ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Rashmi Tambe
Ranch Hand

Joined: Aug 07, 2001
Posts: 418
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.

Hope this answers your question.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
I agree. Here's the link:
subject: Model entity classes in the system
It's not a secret anymore!