This is from the Java SE11 Certification book (Section 12.5.2)
I am having a hard time understanding this below statement in this section discussing about Polymorphism and why relying only on the type of the variable available at compile time is too restrictive.
"For example, if you define a reference variable of type java.util.List, the compiler must not allow the code to invoke methods defined in some other class using that variable."
Why should it not allow ?
OCJP 11 - 12.5.2 Bridging the gap between compile time and run time
Moderator: admin
-
- Posts: 21
- Joined: Mon Sep 30, 2019 9:48 pm
- Contact:
-
- Site Admin
- Posts: 10398
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: OCJP 11 - 12.5.2 Bridging the gap between compile time and run time
The compiler tries to prevent errors due to obvious coding mistakes as much as possible. Let's say you have this code:
Animal a = new Dog(); //Animal has eat method
Vehicle v = new Car(); //Vehicle has drive method
v.eat();
Obviously, invoking eat() on Vehicle is a coding mistake. If the compiler allowed this to succeed, it will fail at run time because, Vehicle does not have eat. This coding mistake should be fixed at coding time itself. No need to wait till program execution to find out that you made this mistake.
There are some languages that allow this. Java doesn't. There are merit and demerits of each approach but Java design philosophy does not allow such calls.
Polymorphism loosens up this restriction a little bit by allowing you to cast a variable to another related type and then invoke methods available in that type.
Animal a = new Dog(); //Animal has eat method
Vehicle v = new Car(); //Vehicle has drive method
v.eat();
Obviously, invoking eat() on Vehicle is a coding mistake. If the compiler allowed this to succeed, it will fail at run time because, Vehicle does not have eat. This coding mistake should be fixed at coding time itself. No need to wait till program execution to find out that you made this mistake.
There are some languages that allow this. Java doesn't. There are merit and demerits of each approach but Java design philosophy does not allow such calls.
Polymorphism loosens up this restriction a little bit by allowing you to cast a variable to another related type and then invoke methods available in that type.
-
- Posts: 21
- Joined: Mon Sep 30, 2019 9:48 pm
- Contact:
Re: OCJP 11 - 12.5.2 Bridging the gap between compile time and run time
Thank you so much for the explanation. I get it now.
So what you meant in the text is that if i have a reference variable of type List (i.e List<Double> listDouble;) and i tried to invoke method of some other class (meaning a non List class) using that list reference variable (as in listDouble.xyz()) , then its a coding mistake and should not be allowed. Polymorphism loosens up this restriction by the use of cast.
For some reason, i kept thinking in my head when i read "invoking method using that variable" that the variable is being passed to some other classes method as a parameter.
So what you meant in the text is that if i have a reference variable of type List (i.e List<Double> listDouble;) and i tried to invoke method of some other class (meaning a non List class) using that list reference variable (as in listDouble.xyz()) , then its a coding mistake and should not be allowed. Polymorphism loosens up this restriction by the use of cast.
For some reason, i kept thinking in my head when i read "invoking method using that variable" that the variable is being passed to some other classes method as a parameter.
Who is online
Users browsing this forum: No registered users and 10 guests