Overridding

[Kareem Qureshi]

This question is from certification4career sample #1
55)
When can't you override a method?
a.when method is declared abstract
b.When method is declared final
c.when method is declared private
d.when method is declared static
I have answered b,c,d
the answer given is only b
My understanding is that when a method is static in the super class then it couldnt be overridden it is hidden, when a method is private then it cannot be overridden
Please advice
Thanks in advance
kareem

[Valentin Crettaz]

In the strict sense of overriding, the correct answers are b,c,d as you answered. Static methods are hidden and not overridden, private methods cannot be overridden (although nothing prevents you to declare a method with the same signature in a subclass) and final methods cannot be overridden either.
Again, forget about certification4career, they are obviously not professional. No harsh feeling guys (@certification4career), but if you pretend doing good mock exams for certifications, at least make some effort to word the questions and answers properly

[Anthony Villanueva]

Hi,

My understanding is that when a method is static in the super class then it couldnt be overridden it is hidden, when a method is private then it cannot be overridden.

A private method in a superclass cannot be overridden by a method with an identical signature in its subclass, although you can have both methods around. The subclass is "unaware" of all private members of the super class.
The point of overriding a method is that it supports polymorphism, i.e. a single object reference can invoke different behavior at runtime depending on the actual runtime object pointed to by that reference. Static methods are normally invoked by the class, not by a class instance, so...
-anthony

[everbeen]

Hi,
The answer is B.
You can override a method the declared private, and you can declare the overriding method private, defult, protected or public.

[Anthony Villanueva]

You can override a method the declared private

Well, no. You can have both method signatures on the superclass and the subclass, but there is no override.
Try this:

public class Base
{
public static void main(String args[])
{
Base b = new Base();
b.f(); // must display Superclass

b = new Derived();
b.f();// must display Superclass; no override occurring    :)  

Derived d = new Derived();
d.f();// must display Subclass
}

private void f()
{
   System.out.println("Superclass");  
}
}

class Derived extends Base
{
      public void f()
      {
         System.out.println("Subclass");  
      }
}

you can declare the overriding method private, defult, protected or public

Well, again, no. The overriding method must be at least as restrictive as the overriden method, if not less restrictive. Try this:

class Base2
{
public void m()
{
   System.out.println("Superclass");  
}
}
class Derived2 extends Base2
{
protected void m()
{
   System.out.println("Superclass");  
}
}

and you will have a compile time error.
Oh BTW, I think you should change your name before the bartender catches you
-anthony
[ March 30, 2002: Message edited by: Anthony Villanueva ]
[ March 31, 2002: Message edited by: Anthony Villanueva ]

[Rob Ross]

Another helpful way to understand why private methods can't be overridden, besides understanding that they are not inherited, is to understand that all private methods are implicitly final. You can include the final modifier keyword if you wish, although it is redundant. But realizing that private methods are final should be another way to help you remember that private methods can't be overridden.

[Anthony Villanueva]

private methods can't be overridden, besides understanding that they are not inherited[italics mine]

I've always wondered about that, so I wrote this code:

public class Test
{
public static void main(String args[])
{
Base b = new Base();
Base.Derived d = b.new Derived();
d.show();
}
}
class Base
{
class Derived extends Base
{
public void show()
{
super.m();
System.out.println("value:" + super.i);
}
}
private int i = 0;

private void m()
{
System.out.println("private!");
}
}

Since I'm getting an output, I can only conclude that the subclass actually inherited the private methods and instances of the superclass.
So okay, I cheated by using an inner class to break the privacy restrictions, but still...
-anthony
[ March 31, 2002: Message edited by: Anthony Villanueva ]

[Thomas Paul]

An inner class has access to all the methods of the outer class, even the private ones.

[Anthony Villanueva]

An inner class has access to all the methods of the outer class, even the private ones.

True, but I used super.m() and super.i and we know that the super keyword cannot be used to access the instance members of an arbitrary outer class...
That is to say, if Derived was using its privilege to access m() and i, it would have been sufficient to use

public void show()
{
m();
System.out.println("value:" + i);
}

which would be correct, but please note I used

public void show()
{
super.m();
System.out.println("value:" + super.i);
}

which is different.
-anthony
[ March 31, 2002: Message edited by: Anthony Villanueva ]
[ March 31, 2002: Message edited by: Anthony Villanueva ]

[Rob Ross]

You can actually call either, because the scope of the call is such that method m() is accessible to your show() method, whether you use the superclass' reference or not.
Contrast this to defining the Derived class outside of Base, ie, so it's not nested. Then you won't be able to access m().
You are only able to access the private member m() because you are refering to it in a context that allows it, namely, within the same accessible scope.
[ March 31, 2002: Message edited by: Rob Ross ]

[Anthony Villanueva]

Basically, I think the whole point boils down to this: is being accessible and being inheritable two different things or not? I think they are.

You can actually call either, because the scope of the call is such that method m() is accessible to your show() method, whether you use the superclass' reference or not.

Yes, definitely no argument there but the point I wanted to make was that calling m() as simply m() vis-a-vis calling m() as super.m() are two different things.
If Derived did not extend Base, then calling super.m() would have been pure nonsense, even if Derived is an inner class of Base. The whole point of using an inner class was simply to break Base's encapsulation so that super.m() can is now accessible.
And what does invoking super.m() mean anyway? Why, asking the Java genie inside the box: "Hey, my superclass has a method named m(). Lemme have it."
And he squints an eye and says: "Wait a minute, are you a subclass?" :roll:
And I say: "Heck yes, I'm using super, aren't I?"
And he says: "Yeah, ok you got this far, fine here's you go."
-anthony

[Valentin Crettaz]

Since I'm getting an output, I can only conclude that the subclass actually inherited the private methods and instances of the superclass.
The bottom line is (as Rob said) that a private method is implicitely final (8.4.3.3 final Methods) and thus can't be overridden.
I liked the little speech of your Java Genie ( ) so here is one between a subclass (Dog) and its superclass (Mammal):
Dog: "Hey, Mammal, I know you already define the walking behavior of our instances, but I'd like to refine it since my instances can wag while walking. I promise I'll just add that wagging thing and I'll let you handle the walking part. How does it sound?"
Mammal: "Well, yeah, why not... Just do it by prefixing your invocation by super..."
Dog: "Got it, thanks, and by the way, do you know that some of my instances may not have hairs, so I'd like to modify that too, may I?
Mammal: "What? Dogs, without hairs? That must be some crazy idea of your instances' owner, right? All mammals are supposed to have hairs and be warm-blooded I can't just let you change that. No way, sorry!!"
Dog: "But,..."
Mammal: "No way, I said, you are never gonna be able to change that, that's why I'm declaring that feature private and that's my final decision!"
Dog: "Ok, ok, I'll cope with that. But nothing will prevent me to implement my own hasHair() feature, so that my no-hair instances may be truthful about that."
Mammal: "Whatever, but I won't help you..."
Dog: "I don't care..."
The code that refers to that speech:

class Mammal{
   public void walk(){
      //do something
   }
   //all mammals have hairs. This method is not meant
   //to be invoked directly but through the toString() method
   private boolean hasHair(){
      return true;
   }
   public String toString(){
      String s = "Mammals=[";
      s += "Hair:"+hasHair();
      //...
      s += "]";
      return s;
   }
}
class Dog extends Mammal{
   public void walk(){
      super.walk(); //you can do this because walk is inherited
      wag();
   }
   public boolean hasHair(){
      //you cannot do this because hasHair() is not inherited
      boolean hair = super.hasHair();
      //...do something with that hair boolean
   }
   private void wag(){
      //...
   }
}

[ March 31, 2002: Message edited by: Valentin Crettaz ]

[Anthony Villanueva]

Mammal: "Well, I'm glad that was over." :roll:
Dog: "Um, I still don't get it..."
Java(TM)Genie: "Well, weren't you paying attention?

A class inherits from its direct superclass and direct superinterfaces all the non-private methods (whether abstract or not) of the superclass and superinterfaces that are accessible to code in the class and are neither overridden (�8.4.6.1) nor hidden (�8.4.6.2) by a declaration in the class.

It's the specs man!"
Dog: "Well I'll be a son of a ...! So what was that output I was seeing?"
Java(tm)Genie: "Your tail, heh he... Well, back to herding cows you go... and stay away from those damn rabbits..!"
-anthony
[ March 31, 2002: Message edited by: Anthony Villanueva ]
[ March 31, 2002: Message edited by: Anthony Villanueva ]

[Valentin Crettaz]

That's point I was trying to show you, anthony. I know you know that private methods are not inherited so don't make a big deal out of this