It depends on what exactly you are doing. Sometimes it is appropriate to use instanceof and sometimes not. For instance, consider a square class that extends a rectangle class. Clearly a square of width 5 should be considered 'equal' to a rectangle of width 5 and height 5, regardless of whether or not they are the same class, in this case instanceof is appropriate. Then consider a "Health Professional" class which has two subclasses, a "Surgeon" and a "Nurse." Suppose equality of health professionals is define by their experience and number of peer reviewed publications. Does that mean a surgeon and a nurse both with ten years of experience and six published papers are equal? Certainly not, the surgeon is far more skilled and likely has ten nurses lining up to suck his dick, so here getClass() would be appropriate. If you are really stuck post what classes you are modelling and I'll have a look.
What he means is, use a true class based object oriented system. Java is not. Class based OOP demands that everything is an object. You should now realize why this is. Java does not. See: int versus Integer.
Ditch your shitty poorly thought out langauge/framework for something that wasn't coded using the million monkey principal.
Name:
Anonymous2009-05-18 6:07
For instance, consider a square class that extends a rectangle class.
Hoo, boy. A standard interview question you just flunked!
Name:
Anonymous2009-05-18 6:09
>>4 monkey principal
What a silly high school you went to.
OP here. I'm making a simple public final class Time implements Comparable<Time> with only a couple of fields (hours, minutes, seconds).
// The teacher said to keep it simple (lulz).
>>3
Surgeon is not a subclass of Man, and is not guaranteed to have a publically accessible Dick object.
I suggest wrapping the Surgeon Object in a adapter before passing it to serve the NurseQueue.
Name:
Anonymous2009-05-18 17:03
>>5
Anybody who thinks rectangle should extend square is just plain retarded.
Name:
Anonymous2009-05-18 17:05
>>14
A rectangle is a special case of a square (ie. it's a square with irregular sides)
>>17
It appears to take the atypical argument that because a square cannot do everything a rectangle can do it can't be a subclass. This is entirely false- namely because the premise is false and the scale(double x, double y) method is a good example of this. It's argued a rectangle would have such a method but a square cannot have such behavior because it would no longer be a square. What is wrong here is assuming any class of a rectangle when scaled is still that same class of a rectangle, not that the square can't satisfy the specified behavior. The solution would be a mutable Shape system, and then having scale return an object of type Shape or Rectangle- not simply attempt to transform a Square.