• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Two different subclass objects within an arraylist.

 
Jason Job
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have four classes that are necessary to know about here.

Employee : Superclass with common variables.
ProductionWorker : subclass with specific variables
ShiftSupervisor : subclass with specific variables (Such as productionGoals)


Shift : Creates an ArrayList that takes previously generated names from a ProductionWorker ArrayList and ShiftSupervisor ArrayList (made in another class) and adds them to an Employee ArrayList. The idea is for there to be 5 ProductionWorkers and 1 ShiftSupervisor on each Shift.

My question : I have an accessor within ShiftSupervisor that is called getProductionGoals(), in the Shift class I am looking to retrieve the productionGoals and use an if statement to compare a new random # and productionGoals. However, I have no idea how to do that as my acessor isn't accessible using the . operator.


 
Jason Job
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

To be more specific, I can use this

getName is an accessor declared in the Employee class, but I can't use getProductionGoals which is declared in ShiftSupervisor. Is there any way to override that?
 
Stephan van Hulst
Bartender
Posts: 5334
48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My opinion is that usually, when you find yourself using the instanceof operator (outside the equals method) your design is poor.

Instead, you should make a class Shift, that has one (or more) Supervisors, and a list of Employees. You can then directly query the supervisor of a shift for the goals (or even better, query the shift itself for the goals) without having to iterate over all the employees.

Remember that software is here to make real life simpler, not to model real life realistically.
 
Paul Clapham
Sheriff
Pie
Posts: 20719
30
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alternatively you could change your Employee class to have a getProductionGoals method which returned an empty list, or whatever would make sense based on your design. Then a ProductionWorker's list of goals would be empty, because it would inherit this method, but a ShiftSupervisor would have a list of goals based on code in the ShiftSupervisor class.

This might or might not be a good idea; sometimes it's a good idea to put trivial base code in a base class and sometimes it isn't, in which case you need a design like the one Rob Spoor just described. I can't state a rule for when to do one and when to do the other, except if you find yourself doing something which sounds really silly, it's probably wrong.
 
Stephan van Hulst
Bartender
Posts: 5334
48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:[...] in which case you need a design like the one Rob Spoor just described.


I'm curious about this design. Do you have a link? :cool:
 
Paul Clapham
Sheriff
Pie
Posts: 20719
30
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oops... that wasn't Rob at all. Stephan. Sorry about that!
 
Jason Job
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just ignore this for now, my question is effectively null until I figure out wtf this lab is trying to get me to do. I'm stupid, sorry! BRB
 
Stephan van Hulst
Bartender
Posts: 5334
48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's hard to say without knowing the specifics of your assignment.

Note that it's not possible to override the equals() method* in a subclass of a class that already overrides it*. According to Joshua Bloch, one of the former lead designers at Sun, it's impossible to do so without violating the Liskov Substitution Principle.

I'm not sure I agree with him, but he is a career of experience ahead of me, so it's hard to argue with that.

* in a meaningful way.
 
Campbell Ritchie
Sheriff
Posts: 48370
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you might be exaggerating what Bloch says about violating the Liskov Substitution Principle (LSP). You are looking for Joshua Bloch Effective Java™ (2/e, Santa Clara, California: Sun Microsystems Press, 2008), pages 33-44. You may be able to find the old edition here (legally). You find that adding a field to a subclass will violate the LSP. It is worth reading that chapter carefully.
 
Campbell Ritchie
Sheriff
Posts: 48370
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never write
if (somethingBoolean) boo = true; else boo = false;
You write
boo = somethingBoolean;
 
Stephan van Hulst
Bartender
Posts: 5334
48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:I think you might be exaggerating what Bloch says about violating the Liskov Substitution Principle (LSP). You are looking for Joshua Bloch Effective Java™ (2/e, Santa Clara, California: Sun Microsystems Press, 2008), pages 33-44. You may be able to find the old edition here (legally). You find that adding a field to a subclass will violate the LSP. It is worth reading that chapter carefully.


Well, Bloch says that using getClass instead of instanceof violates the LSP, regardless of whether you add a value component or not. You can not override the equals() method in a non-trivial way when the superclass uses the instanceof operator. Doing so will always break the method's contract.
 
Winston Gutkowski
Bartender
Pie
Posts: 10086
55
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:Well, Bloch says that using getClass instead of instanceof violates the LSP, regardless of whether you add a value component or not. You can not override the equals() method in a non-trivial way when the superclass uses the instanceof operator. Doing so will always break the method's contract.

Which is why I generally make my equals() methods final. You can always unlock them later if you decide to refactor; but I have an aversion to getClass()-based equality methods on principle (probably loosely based on LSP ), although I notice that they seem to be gaining popularity in schools.
It's also worth noting that he (Bloch) does offer an alternative - a "view" method - in the same discussion (pp39-40 of EJv2).

Winston
 
Stephan van Hulst
Bartender
Posts: 5334
48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, I always use instanceof, and make my classes final wherever I can. I'm just saying I don't agree with the fact that the getClass way of doing things breaks LSP. It puts a restriction on the use of the equals method, but it doesn't break anything.

If overriding the equals method means breaking substitutability, that means overriding *any* method in a meaningful way breaks it.
 
Winston Gutkowski
Bartender
Pie
Posts: 10086
55
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:Oh, I always use instanceof, and make my classes final wherever I can. I'm just saying I don't agree with the fact that the getClass way of doing things breaks LSP. It puts a restriction on the use of the equals method, but it doesn't break anything.

Actually, it does; just not as obviously perhaps.

If I have a class that contains a Collection of some class that implements a getClass()-based equals() method - Bloch uses the example of a set of Points - and I want to implement a contains(Point) method for it; the method will fail (or actually, even worse, may fail, depending on the type of Collection) if passed a subclass of Point even if it refers to the same location.

This means that, in order to subclass, you may have to refactor classes that merely accept a Point, simply because you can't substitute its equals() behaviour.

instanceof has its problems too, but maybe I'm just more used to them .

Winston

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic