2

Could somebody please give their input into the following scenario:

I have an Administrator class and a Technician class (both extending a User class but that is besides the point). I also have a RepairJob class which represents an item through its varying stages of being repaired {received|being repaired|waiting for part, etc.}.

Only administrator users will be able to add a new repair job to the system and will also be able to view the status of all the repair jobs currently ongoing.

Technicians will need to be able to accept repair jobs from a view of the list of any repair jobs which have not yet been accepted by other technicians. Technician uses will also have to be able to update the status of a repair job accepted by themselves until it's ready to be returned to the Customer (another class).

An administrator will be able to accept any repair job in the system, even those already accepted by a Technician at which point they will no longer be able to update the status of the repair job. (To take account of employees being off work)

My Question

Could somebody give me an insight into how you would collect together the RepairJob instances. I had thought at first that since the administrator user would be adding these instances that it would be a good idea to model the collection inside the Administrator class however the Technician class will also have to be able to access a limited collection of repair jobs. I had also though of creating a RepairJobs class which had the list and was available to either class but I'm not sure if this would be a good design.

Improve this question

2 Answers 2

Reset to default
2

I think it ought to be separate from Admin and Tech classes. RepairJob is for a single task; what you're describing sounds like a RepairJobManager that maintains a collection of RepairJobs and tracks their status. It executes your rules according to the Role of the particular User that interacts with it.

package model; public class RepairJobManager { private Map<String, RepairJob> jobs; public void add(RepairJob job, Role role) { // Only allow Admin to do certain things. } public void update(RepairJob job, Status status, Role role) { // Only allow Admin to do certain things. } }
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Thanks, that confirms my thoughts. I was also considering having only a User class which had a collection of roles (i.e. Administrator, Technician) but that would mean that this class would then hold a collection of RepairJob classes in line with the role(s) the user had... what do you think? Regards JLove
Yes, that's what I think it needs to do. The RepairJob ought to have history inside of it: creation time stamp and maybe a status history, right? The Role is just passed in to allow you to execute rules as needed. I'd have to know more about your requirements to do a better design job.
I would recommend having a User class, but then have a Role that HAS-A User. Let the Role wrap the User and decorate it with authorizations. That way a User can have several Roles.
Thanks very much! I've had a look at the Decorator Pattern and I think this will solve my issue perfectly. I intend to do as you suggest by decorating my User with methods appropriate to the user's role e.g. For Admin users I'll add addUser`removeUser` methods etc. Cheers Again!!
1

My DDD view: You need a RepairJobRepository which holds a collection of RepairJobs. Also you need a RepairService with operations like - create(RepairJob jobSpec) (add the created job to the repository) - assign(RepairJob job, Role role)

RepairJob need a method like updateStatus(Status newStatus, Person p)
You need to get p's role to validate if he could update the status.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.