Advice/Help with project design!

[asif49]

I have to complete a project about employees and their jobs.

The requirements include:
Setting multiple jobs for an employee
etc. etc.

Two of the obvious classes I have for this are the Employee and Job class which hold individual employees and work like this:

private Employee[] e = new Employee[1000];
private Job[] j = new Job[1000];
e[0] = new Employee("Arthur");
e[1] = new Employee("Jane");
j[0] = new Job("Cooking");
j[1] = new Job("Cleaning");

This allows me to manage behaviour of individual employees and assign whichever jobs to whichever employee I like. But I also have another class called EmployeesOnSystem and JobsOnSystem where, the total list of employees/jobs are kept in a List and can be returned with a method, so I have to register the above employees/jobs first like so...

private allEmployees = new EmployeesOnSystem();
private allJobs = new JobsOnSystem();
for (int i = 0; i < e.length; i++) { //register each employee
allEmployees.register(e[i].getName);
}
for (int i = 0; i < j.length; i++) { //register each job
allJobs.register(e[j].getName);
}

It would be simple to store a list of all employees with the original employee class and all jobs within the original job class but since I've heard each class should be only dependent on itself and only have methods/behaviours that are totally relevant to it.

Would it be a bad idea to have a separate class to hold all employees/all jobs on system or is it better to do it like this?

[jackmaverick1]

You should use a list or vector instead of arrays. This would prevent people inputting more than 1000 employees or jobs.

I think that you should not have the JobOnSystem/EmployeeOnSystem class (in my opinon), instead I think you should make the two arrays Lists and start by making the needed methods, etc. I might make the employee and job class first.

[asif49]

I have already created the Job and Employee classes, I can easily incorporate the JobsOnSystem class's methods into the Job class and EmployeesOnSystem's methods into the Employee class. This is what I'm guessing you're suggesting would be the better option ???

[JamesCherrill]

What happened to your Company class? That's where you should have the lists of Employees and Jobs.

[asif49]

Yeah, the Company class is the place from which I create all the Employees and Jobs like you've said. But I still dont understand whether I should have a separate class to print all the employees and jobs for me.

[JamesCherrill]

Why would you need another class for that? The Company class has the lists of all the Es and Js, so that's the obvious place to have the print methods for them.

It would be simple to store a list of all employees with the original employee class and all jobs within the original job class...

Discussion: It's possible to store a list of all the E's as a static variable in the A class, but what happens when you have two Companies in the system? Each Company has it's own list of Es, and you don't want to mix them up. If the lists are part of the Company class then you're OK.

... I've heard each class should be only dependent on itself and only have methods/behaviours that are totally relevant to it.

That's almost true, but in reality classes are dependent on other classes (eg - Employee depends on the String class, Company depends on Employee and Job). Any application has a number of inter-dependent classes, but you don't want then all tangled together like spaghetti. The best designs build the classes in layers, where each class in each layer depend only on classes below and alongside it, but never on the classes above it.
In this case Employee and Job are at the bottom, dependent only on each other. Company is above them, depending on them both. The user interface (if you put that in its own class) is at the top level, depending an all the other three. But there are no "upwards" dependencies.

[asif49]

Very true, I don't know why I didn't look at that although it was the most obvious solution. Was too busy thinking "more classes mean better design".

Also, do you think Company should be a better name or should I call it "Administrator". The reason I say this is because this is the part where all the admin tasks are handled however in the future there may be need for an Employee to have a lot of interaction with the system and if this one is called Admin, the other one can be called Employee or User

[JamesCherrill]

Yes, Administrator seems OK to me. Or maybe Employer? I would go with Employer or Company personally. I would save Administrator for a user interface class (maybe both Administrator and Employee could be subclasses of User - Users have logon IDs, passwords, privileges etc).
Employer/Company has methods like addEmployee or assignJobToEmployee - simple methods that take Employees & Jobs as parameters. Administrator would be a user interface class that has the menus for all those functions, and reads/parses the user input before calling the methods in Employer/Company.