Reputation: 182
Java, in theory, doesn't support member overriding so I was thinking whether this code snippet can be used for overriding members of the class. However, I am not quite sure in what situations this code might fail. I mean, if this works perfectly then it wouldn't go unnoticed right? It might be a stupid question, but I really want to know what this code might do in different situations which my mind can't think of. So it will be really great if someone can explain it to me. Thanks!
class ClassA{ int i = 10; void eat() { System.out.println("In Class A: Eating"); } void bark() { System.out.println("In Class A: Barking"); } } class ClassB extends ClassA{ //int i = 20; ClassB(){ super.i = 20; //Changing the value of i in class A. } void eat() { System.out.println("In Class B: Eating"); } } public class Main{ public static void main(String[] args) { ClassB b = new ClassB(); System.out.println(b.i); b.eat(); b.bark(); ClassA ua = new ClassB(); System.out.println(ua.i); ua.eat(); ua.bark(); ClassA a = new ClassA(); System.out.println(a.i); } }
Upvotes: 1
Views: 108
Reputation: 140407
I am not quite sure in what situations this code might fail.
It (sort of) fails on the human reader/conceptual level.
The java language is what it is. This means that java programmers know what to expect, what to do, and what not to do.
And one of the basic rules for inheritance (in java, but also in general): you are extremely cautious regarding fields of your super class(es). Member fields should be considered an internal implementation detail of a class. You don't expose it to the outer world. You don't expose it to your child classes, unless there is a really good reason to do so. And if you really want to do that in java, then the correct way is: using the protected
keyword for that field.
Your idea is basically that the child class "knows" about super class fields, and worse: changes that "internal state" at creation time.
Thus, in the real world, such code might quickly lead to all sorts of nasty surprises. Because people in the real world wouldn't expect that a subclass is doing something like, thus they might be really surprised to find "i should be 10, why is it 20" when debugging a problem in a large application.
Long story short: the fact that you can do something doesn't mean that you should do it. To the contrary: good programming is about doing things in "standard" ways that do not surprise your readers.
Upvotes: 2
Reputation: 15824
Simple answer for your question is 'Yes', your eat method of class ClassA is overriding in class ClassB. The easy option to verify, is using @Override annotation.
In a subclass, you can override and overload an instance method. Override means, you are subclass replacing the inherited behavior. Overloading means, you are extending the inherited method.
If you modify your ClassB as follows , it will compile successfully.
class ClassB extends ClassA{
//int i = 20;
ClassB(){
super.i = 20; //Changing the value of i in class A.
}
@Override // **Added line is here**
void eat() {
System.out.println("In Class B: Eating");
}
Upvotes: 0
Reputation: 70257
If you override a method then try to call it from the parent, the parent calls the derived method, even though it wasn't aware of it at definition time.
class A {
public void foo() {
System.out.println("A.foo");
}
public void callFoo() {
this.foo();
}
}
class B {
public void foo() {
System.out.println("B.foo");
}
}
B instance = new B();
instance.callFoo(); // Prints "B.foo"
Now if we try to do the same thing with instance fields, we get the original one.
class A {
public String foo = "A.foo";
public void printFoo() {
System.out.println(this.foo);
}
}
class B {
public String foo = "B.foo";
}
B instance = new B();
instance.printFoo(); // Prints "A.foo"
So we haven't actually overridden anything; we've simply made a new variable that happens to confusingly share the name of an existing one. If it was true overriding, then we would be able to augment the behavior of A
methods which use that variable but aren't aware of the subclass.
Upvotes: 0