Win a copy of Cloud Native PatternsE this week in the Cloud forum
or Natural Language Processing in the AI/ML forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Overriding

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

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.

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 ]
 
Ranch Hand
Posts: 805
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 805
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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".

    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
    Ranch Hand
    Posts: 504
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi everyone,
    There is more to the default access modifier in terms of overriding and overloading.
    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
    Ranch Hand
    Posts: 805
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    Ranch Hand
    Posts: 443
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator





    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
    Ranch Hand
    Posts: 504
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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 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
    Ranch Hand
    Posts: 805
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 504
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Who can explain what happens here and why?

    Will this code ever compile? Will Daniel ever marry Franceska as asked in one popular textbook?
    Thanks.
     
    Jeff Bosch
    Ranch Hand
    Posts: 805
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    Ranch Hand
    Posts: 2120
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 504
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 504
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 504
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 2120
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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 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
    Ranch Hand
    Posts: 504
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I apologize Jose, I meant
    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
    Ranch Hand
    Posts: 2120
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.

     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!