Overloaded methods question

Question

I guess I don't understand overloaded methods as well as I thought I did, because I'm confused about some behavior I'm seeing in my Java program. Here's a sample program that I wrote up to demonstrate the issue:
public class Polymorphism
     static class Shape
          public void test()
               System.out.println( "In Shape" );
     static class Rectangle extends Shape
          int height, width;
          public Rectangle( int height, int width )
               this.height = height;
               this.width = width;
          public void test()
               System.out.println( "In Rectangle" );
          public boolean equals( Rectangle rect )
               return ( height == rect.height ) && ( width == rect.width );
     public static void main( String[] args )
          Shape shape = new Rectangle( 5, 7 );
          shape.test();
          Shape shape1 = new Rectangle( 3, 4 );
          Shape shape2 = new Rectangle( 3, 4 );
          System.out.println( shape1.equals( shape2 ) );
          System.out.println( ((Rectangle)shape1).equals( shape2 ) );
          System.out.println( shape1.equals( (Rectangle)shape2 ) );
          System.out.println( ((Rectangle)shape1).equals( (Rectangle)shape2 ) );
}And the output looks like this:
In Rectangle
false
false
false
trueThe first call to "test()" calls the Rectangle's test method, as I would have expected. This happens despite the fact that shape is declared as a Shape.
Here's where I get confused. I would have thought the next four calls to println would have output "true" every time, because shape1 and shape2 are Rectangles, hence, I would have expected that Rectangle's "equals()" method would have been called each time. But apparently it's only being called in the last case, when I cast both shape1 and shape2 to be Rectangles. (Presumably, Object.equals() is being called, and it's appropriately returning "false" because the objects are not the same instance.)
So this behavior seems inconsistent to me. Why did the first call to "test()" invoke Rectangle.test() even though I declared it as a Shape, yet the succeeding calls to shape1 invoke Shape.equals() rather than Rectangle.equals(), despite the fact that the objects are truly Rectangles?
Can anyone explain this to me, or point me to a tutorial that would describe this behavior?
Thanks.

Answer 1

Case 1 and Case 2 seem analogous to me, yet their
behaviors are different. (There is one difference
between the two cases, and that is that in case 1 I'm
overriding the test() method, while in case 2 I'm
overloading equals(). Overriding vs. overloading.
Though clearly these are different concepts, I guess
it never would have occurred to me that whether a
method was overridden vs. overloaded made such a
difference in how invocation worked.)You're right: it's the diffference between overriding and overloading.
I'll try to formulate it differently:
At compile-time, the compiler, based on the declared type of the Object the method's called on, and based on the declared types of the arguments, determines which method'll get called (a method is defined by its name and its signature. I don't think the return type matters in this context).
In the test() case, the compiler looks for a method in class Shape and finds: test().
In your "third case", the compiler looks for a method named "equals" in class Shape with the argument type: "Rectangle", finds none, so it takes: equals(Object)
At runtime, the method is looked for in the Object it's invoked on, that is a Rectangle.
In the test() case, it looks for the method: test(). Since that is declared in the Rectangle class, it takes the overridden method.
But in the "third case", there's no equals(Object) method, so it takes the super.
So I apologize if no one can think of a way to make
this clearer to me, but I still have some subtle
confusion on the issue.It is a confusing topic. That's why I pointed out itchyscratchy's reply, who made a good point telling to avoid having to rely on overloaded methods generally. Overriding is complicated enough.