• Post Reply Bookmark Topic Watch Topic
  • New Topic

Interfaces - Inheritance and design  RSS feed

 
Gary Fletcher
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a application that uses the class structure below. I am not too sure that I have used the best/correct design as I am feel that the code looks "dirty". With the below in mind I have the following questions.

1. Given that I want a data sructure (array or collection) to hold all Employees, of any type should I have an array, ArrayList, Hashmap of Employee or IEmployee?
2. I am not happy that the Technical and Manager classes have to give implementations of getC() (Technical) and getD() (Technical and Manager) as these are declared in the interface (IEmployee), is there a better way? I want to be able to call any method in whichever Employee representation I am currently referencing.
3. As the Manager is the super class of Director I have had to add an extra Levels argument to its constructor, this doesn't "feel" right. Again, is there a better way?

Thanks for any advise.


 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You have several questions there. I am not sure what the best “container” for your objects is. I know ArrayList is the most popular type of “container”, but it might not be the best. Start reading about collections here.

Since your methods have such poor names, I don't know what they are supposed to mean, so I don't know whether they are good design, but I suspect not. I am always suspicious of subclasses which add fields or methods to their superclasses. It makes it awkward to use a declared reference and get the full functionality from the runtime type. Somebody had a similar problem yesterday. There is a problem with ArrayList#ensureCapacity(int) which we discussed last year.
I would not call an interface IAnything. It should be Employee. And the abstract class should be AbstractEmployee, as in the inheritance diagram shown here.
There are some things which are common to all employees, e.g. name, start date, pay. Some things which are not common, e.g. bonus. You could have methods in the abstract class like this:-Not sure what else to suggest at the moment.
 
Gary Fletcher
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply Campbell.

Wasn't really concerned about which data structure to use, in my real app I use a Hashmap to store all employee details (indexed on a unique ID value generated on employee creation) and ArrayList for temporary storage, ie when I need to loop thru a subset (after a search) for display purposes.

I am a little unsure about the naming conventions you mention for Interfaces, using your convention how could I tell at a glance the difference between an interface and a concrete class, such as Manager, or would I call the Manager ConcreteManager for the distinction, and what if I had no Interfaces or abstract classes?

Also, in the real app I don't have fields and methods named as in the code proided in original question (a and getA()) but use salary, bonus etc, and getSalary() and getBonus(), setSalary() and setBonus() etc.

I shall certainly read the Tagged questions that you included.
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Worker?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!