Overriding

[TimD Moore]

Hi,
In a subclass, must a method in the parent class be overridden before it can be overloaded? Can a method be overloaded and not overridden?
Thanks,
TM

[Anand R Kulkarni]

Greetings All,
The way I understand is :
Overloading is for "a class" and overriding involves inheritance.( more than one class)..
these two are independent concepts.
In a subclass, must a method in the parent class be overridden before it can be overloaded?
No ( need not be)
Can a method be overloaded and not overridden?
Yes

Regards,
Anand Kulkarni

[Jessica Sant]

Anand's got it right.
It's VERY important to understand the difference between overloading and overriding for the exam (and even just in coding)
Overriding is when a subclass declares a method with the exact same method signature as the superclass. Thus giving the method a new implementation.
Ex:

class SuperDuper{
   public int doubleIt( int i ) {
      return i+i;
   }
}
class Submarine extends SuperDuper {
   public int doubleIt( int i ) {
      return i*2;
   }
}

Now... say you want to be able to double more than just integers -- maybe you want to double floats or shorts or even doubles! That's when you need to overload the method.

class SuperDuper{
   public int doubleIt( int i ) {
      return i+i;
   }
   public float doubleIt( float f ) {
      return f+f;
   }
   public String doubleIt( String s ) {
      return s+s;
   }
}
class Submarine extends SuperDuper {
   public short doubleIt( short s ) {
      return s+s;
   }
   public double doubleIt( double d ) {
      return d+d;
   }
}

Notice that the method doubleIt() was overloaded in both the superclass and the subclass.
*Be VERY careful when overriding a method -- if the signatures don't match EXACTLY you could end up overloading the method instead of overriding it, and you could have some unexpected behavior*
[ August 25, 2003: Message edited by: Jessica Sant ]

[Jeff Bosch]

Just remember the concept of inheritance: A subclass will inherit any members of its superclass not marked private or default (which involves whether or not the subclass is in the same package). This means that the members of the superclass are members of the subclass.
Therefore:
Writing a method with the same signature and return type overrides the method in the superclass;
Writing a method with a different signature (and optionally a different return type) overloads the method inherited from the superclass.
This distinction becomes very important not only in calls to the subclass object's methods, but also when declaring a superclass reference variable and invoking methods through that variable. You need to know the rules for resolving which method will be called in such a case, and the rules depend on whether the called method is overridden or overloaded. (But that's probably another thread, uh, topic...)
Hope this helps!
Regards,
Jeff

[Vad Fogel]

Hi Jeff,
"A subclass will inherit any members of its superclass not marked private or default (which involves whether or not the subclass is in the same package)."
Does this mean some kind of "temporary" inheritance of the methods having default access?
Thanks.
public class Child extends Parent{
public static void main(String[] s){
new Child().doStuff();
}
}//end of Child class
class Parent{
void doStuff(){
System.out.println("Doing stuff!");
}
}//end of Parent class

[Jeff Bosch]

Temporary, no. Limited, yes. Actually, I should have added "protected" to my list.
The following access rules apply to any member of a class:

(no access modifier) -> default access. Any class in the same package can access;

protected -> Any class in the same package, or child classes in other packages can access, but then the inherited child class member becomes private to other classes;

public -> Any class in any package can access, though an import statement may be necessary;

private -> No class except an inner class can access the member.

Note that the term "access" in this list also includes "inherit".

 
package com.a;
class A{ 
    void doSomething(){}
}
package com.b
class B extends A{
    void doSomething( String something ){} // overload
}
class C{
   B b;
   public static void main( String [] args ){
      b = new B;
      b.soSomething( "Bob" ); // no problem, we're in the same package
      b.doSomething(); // error! It became private after inheritance
   }
}

Class B can inherit the protected member, but only it and its instances can access it.
Regards,
Jeff
[ August 26, 2003: Message edited by: Jeff Bosch ]

[Vad Fogel]

Hi everyone,
There is more to the default access modifier in terms of overriding and overloading.

package a;
public abstract class Base{
   void doStuff();
}
package b;
import a.Base;
public class Sub extends Base{
   public void doStuff(){}
}
  

This will never work because the contract of extending an abstract class can't ever be fulfilled this way.
Similar to that, what you demonstrated in your code, class B extending class A just redefined the method doSomething() with the String argument. To me, I can't call it overloading because B doesn't see doSomething() of A in the first place.
I find this discussion interesting since default access is not believed the trickiest one, but it can give some pain anyway.
Thanks,

[Jeff Bosch]

Could you please elaborate, Vad?
In my understanding of protected access, B inherits the protected method(s) of A (though I did omit the import statement), but can only use it/them through inheritance, not through a reference to an object of the superclass's type. Because B inherits A's protected members, it can then overload them. Calling this overloading "redefining" may be correct or it may be "splitting hairs", but I'm open to correction.
(Anyone else care to join in?)
Thanks,
Jeff

[Alton Hernandez]

 
package com.a;
class A{ 
    void doSomething(){}
}
package com.b
class B extends A{
    void doSomething( String something ){} // overload
}
class C{
   B b;
   public static void main( String [] args ){
      b = new B;
      b.soSomething( "Bob" ); // no problem, we're in the same package
      b.doSomething(); // error! It became private after inheritance
   }
}

Class B can inherit the protected member, but only it and its instances can access it.

Hi Jeff,
In you sample code, class A and B do NOT have any protected members. The access modifier of doSomething() is default.
[ August 26, 2003: Message edited by: Alton Hernandez ]

[Vad Fogel]

That's right, there are no protected members declared in either B or A of Jeff's. Therefore, being put in different packages, B cannot fully benefit from extending A, and the method doSomething() of A is not visible to B. That's why creating doSomething(String str) in B doesn't overload anything. Moreover, you can also create

private void doSomething(){}  

in class B and get away with it - even though the access is weaker than that of the parent class' method. This is not overriding.
Thanks.

[Jeff Bosch]

Ah. Oh. (He said sheepishly. Baa. Baa.)
If you change those to protected, then it will work. My apologies for the omission!
Regards,
Jeff

[Vad Fogel]

Who can explain what happens here and why?

  
package a;
public class MyBase{
   protected void doStuff(){}
}//end of class MyBase
package b;
import a.MyBase;
public class MySub extends MyBase{
   void testIt(){
      doStuff();  //expected result
      //new MySub().doStuf();  //doesn't compile, also well expected
      super.doStuff();   //??
   }
}//end of class MyBase

Will this code ever compile? Will Daniel ever marry Franceska as asked in one popular textbook?
Thanks.

[Jeff Bosch]

I'm going to take a (somewhat) educated guess here:
I think the code compiles as long as another object outside package a doesn't instantiate MySub. If the other class does instantiate it I would expect a compiler error "Method MyBase.doStuff() not found" or somesuch.
Regards,
Jeff

[Jose Botella]

Welcome to the Ranch Vad.
This might help from JLS 6.6.2.1

6.6.2.1 Access to a protected Member
Let C be the class in which a protected member m is declared. Access is permitted only within the body of a subclass S of C. In addition, if Id denotes an instance field or instance method, then:
* If the access is by a qualified name Q.Id, where Q is an ExpressionName, then the access is permitted if and only if the type of the expression Q is S or a subclass of S.
* If the access is by a field access expression E.Id, where E is a Primary expression, or by a method invocation expression E.Id(. . .), where E is a Primary expression, then the access is permitted if and only if the type of E is S or a subclass of S.

[ August 27, 2003: Message edited by: Jose Botella ]
[ August 27, 2003: Message edited by: Jose Botella ]
[ August 27, 2003: Message edited by: Jose Botella ]

[Vad Fogel]

Nice guess it was Jeff. It does compile fine. However, I believe that the package doesn't matter here and super must be available to the subclass under any circumstances when propely called from a non-static context. super is not an instance of the superclass and therefore shouldn't fall behind the protected limitations. Would you agree?
Thanks.

[Vad Fogel]

Thanks for the link, Jose. I liked your interpretation of

super().doStuff() as ((MyBase) this).doStuff()

and gave it an immediate try. It doesn't compile provided that I used the code that I had posted before. Apparently, you can't treat super as anything but super. Upcasting the subclass to its superclass didn't substitute the real instance of the superclass object which is available only thru the call to super in our case.
Thanks.

[Vad Fogel]

I have a question on overriding finalize method: why are we allowed to throw an exception in its signature even though it will be ignored in the body? Does it not violate the notation of overriding or is it just a special case?

[Jose Botella]

Hello again,
Yesterday I was tired and it was too late for me to keep on thinking about this example.
Now I am a bit more fresh and I can see why

//new MySub().doStuf();  //doesn't compile, also well expected

does not compile when it should. There is a missing f because the method is doStuff :roll:
The compile type type of the primary expression "new MySub()" is the same as the class holding the accesing expression.

[Vad Fogel]

I apologize Jose, I meant

//new MyBase().doStuff(); //doesn't compile, well expected

Don't know what I was thinking at that time :roll:
So, what do you think about being able to invoke protected methods thru super, even though the classes are in different packages?

[Jose Botella]

why super.doStuff(); compiles?
I cannot say that super is a Primary expression or a Qualified expression name
My intuitive answer is that super makes sure the two things that according to JLS 6.6.2.1 grant access to a protected member outside the declaring package:
A) the access expression "super.doStuff()" occurs in a subclass of the one declaring the protected member.
B) the access is to the inherited member, not to the one declared in an object of superclass.
This might help to see why super complies with points A and B, from JLS 15.12.2

Suppose that a field access expression super.name appears within class C, and the immediate superclass of C is class S. Then super.name is treated exactly as if it had been the expression ((S)this).name; thus, it refers to the field named name of the current object, but with the current object viewed as an instance of the superclass. Thus it can access the field named name that is visible in class S, even if that field is hidden by a declaration of a field named name in class C.