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.
>>22
But it probably doesn't. You'll have four guys write 5000 LoC each, and then you discover you'll have to rewrite it all because the code is ugly and full of hacks, and it can't be made to work the way you need it to no matter what. And then you rewrite it as a couple of 500 line unmantainable Perl scripts that no one will dare touch in 10 years because they kind of work, despite some small work-aroundable issues.
Name:
Anonymous2009-05-19 3:09
>>20
Great way to dodge the argument. Mind actually telling me why I am wrong? I realise that could well be the case but in the interests of being scientific and ultimately constructive it would be nice if you actually elaborated on why.
Name:
Anonymous2009-05-19 3:56
>>20 >>21
Why not use java.awt.geom.Rectangle2D.Double and java.awt.geom.AffineTransform along with public Shape createTransformedShape(Shape pSrc) instead of reinventing the wheel?
Speaking of retarded you shit heating faggot, in Java int is a "primitive" type. It is not an Object. Integer is an object type. It is the object type for int.
So Sun implemented efficient primitive types with Object implementations.
Instead of doing the fucking right thing and make all types Objects that are efficient.
>>27
This might surprise you but javas "primitive" integers exhibit intelligent autoboxing behaviour, in fact. A primitive integer could even be considered a wrapper around its Integer object that simply hides all the details until neccesary- what better effeciency could you ask for? On the subject of effeciency, java arithmetic is actually benchmarkedly faster than Se and Sepples arithmetic, a testament to the sound design decisions of the Sun Java team.