Develop Reference

How does dynamic polymorphism in java apply to interfaces?

I have been reading about dynamic polymorphism in java recently(I am beginner). As per my understanding if a reference of a parent class type is assigned as a reference to its child like below
tutorialspoint it involves dynamic polymorphism. In the example discussed in the link, I understand an Object of employee class is used to access a (overridden) method of salary class.
In that example neither is employee abstract nor is an interface. (which means it is possible to create an object for the parent).
Now, as per this link stackoverflow, I see that an interface is used to discuss dynamic polymorphism.
Question: How is it possible to use interface as an example for dynamic polymorphism?
Moreover, in the example discussed in tutorialspoint, it is said that compiler look for the method in parent class but JVM invokes the child class method during run time.
Interfaces neither have method definition nor can be instantiated, so how can
List<Animal> animalPen = new LinkedList<>(); be used for dynamic polymorphism.

Actually, the explanation isn't really much different.
List animalPen = new LinkedList<>();
boolean empty = animalPen.isEmpty();
In this example, the compiler validates whether animalPen has a method isEmpty by looking to its reference type List. List declares the method isEmpty and so, even if it does not define it, the system is then guaranteed that animalPen has a defined method by that signature.
This is because a non-abstract class must define all methods from all interfaces it implements. This ensures that all instances of an interface is one which has, somewhere in its hierarchy, defined the interface's methods.

You use interfaces to do polymorphism when you have different behaviours in your objects. Let's say you have a class Duck and you have a FlyBehavior variable declared. In this case the first thing you think of doing is a class named FlyBehavior to make an object of that type. Now let's say you have different type of ducks, like the Mallard duck, Redhead duck and now you have a Rubber duck, all of them extend the Duck class. Your rubber duck will not fly, so FlyBehavior will be different for the rubber duck. So, you make FlyBehavior an interface and create two new classes: ItFlies and NoFly, both implement the FlyBehavior interface. The constructor in Duck will have a a FlyBehavior parameter that you'll need to fill when you create a new object of type Duck, as you say, an interface can't be instantiated, but since ItFlies and NoFly, both implement the FlyBehavior interface, you can fill the FlyBehavior parameter with these two classes (or any class that implements FlyBehavior). This object oriented technique is also useful to make your program more independent and flexible in case of making modifications.

Why Java needs explicit downcasting?

I have seen other answers to similar questions but all of them rely on the fact that the language is defined to be like this. Following is what I am seeking an explanation to:
In an inheritance hierarchy, the parent types can hold child objects implicitly (why?), however for the child references to hold a parent object, explicit downcast is necessary (why?).
Please cite some example that explains why not doing this will fail, I mean using Animal, Dog type etc. If this question is already answered and I have missed it, citing that also will be helpful.
For example:
class Animal{
public void eat(){};
}
class Dog extends Animal{
public void bark(){};
}
class App{
Animal an = new Dog(); //1. why can animal store a dog but not a dog store an animal
Dog dog = (Dog) new Animal(); //2. Dog has the behavior of an Animal so why explicit downcast
}
I just want to know how this lines make sense, other than just knowing they are language semantics. Better if your answer looks like that as a granny explaining this to her grandchild.
Edit:
I just was wondering that Dog inherits Animal and has all the behavior. Hence number 2 above should have been allowed without explicit downcasting.
Or, that (I think I got it now) when I ask a Dog to store an Animal there are possibilities that I actually get a Cow or a Horse, because Animal being parent can hold any of its subtypes. If that's the case then why has Java allowed Animal to hold subtypes since there might be behavior typical to subtypes like a Dog will bark(), for that again compiler has to check and report. I know the rules just trying to reason out in the simplest of sense.

The gain of strict type binding in Java is that you get compile time errors, instead of runtime errors, when possible.
Example:
class Animal {
void eat() {}
}
class Dog extends Animal {
void bark() {}
}
class Pigeon extends Animal {
void pick() {}
}
class MyFunction {
void run() {
Animal first = new Pigeon();
// the following line will compile, but not run
((Dog)first).bark();
}
}
If you have such code in a simple example like this, you will spot the problem at once. But consider having such a problem in a project, in a seldom called function at the depth of thousands of lines of code, in hundreds of classes. One day in production, the code fails and your customer is upset. And its up to you to find out why it failed, what happened and how to fix it. Its a horrible task.
So, with this somewhat complicated notation Java nudges you into thinking again about your code, the next example would be how its done better:
class MyFunction {
void run() {
Pigeon first = new Pigeon();
// the following line will NOT compile
first.bark();
// and neither will this. Because a Pigeon is not a Dog.
((Dog)first).bark();
}
}
Now you see your problem at once. This code, will not run. And you can avoid the problems ahead by using it correctly.
If you make your Animal class abstract (which you should), you will see that you can only instantiate specific animals, but not general ones. After that you will start using the specific ones when required and be relieved that you can reuse some code when using the general class.
Background
Conceptually, runtime errors are harder to find and debug, then compile time errors. Like, seriously hard. (Search for NullPointerException here on Stack Overflow and you will see hundreds of people who struggle to fix runtime exceptions)
In a Hierarchy of things (in general, not programming related) you can have something general "Thats an animal". You can also have something specific "Thats a dog". When someone talks about the general thing, you can't expect to know the specific thing. An animal can't bark up a tree, because birds could not, neither do cats.
So, in Java in particular the original programmers found it wise to decide that you need to know an object specific enough to call the functions of that object. This ensures that if you didn't pay attention, the compiler will warn you, instead of your runtime.
Your particular case
You assume that:
Dog dog = (Dog) new Animal();
should work, because a Dog is an Animal. But it won't, because not all Animals are Dogs.
BUT:
Animal an = new Dog();
works, because all Dogs are Animals. And in this specific case
Animal an = new Dog();
Dog dog = (Dog)an;
will work too, because the specific runtime state of that animal happens to be Dog. Now if you change that to
Animal an = new Pigeon();
Dog dog = (Dog)an;
it still WILL compile, but it WILL NOT run, because the second line Dog dog = (Dog)an; fails. You can't cast a Pigeon to a Dog.
So, in this case you WILL get a ClassCastException. Same if you try to cast new Animal() to Dog. An Animal is NOT a Dog. Now, that will happen at runtime and that is bad. In the Java way of thinking, compile time errors are better then runtime errors.

Yes. One simple real time example to understand the theory is
Every Truck driver is Driver but not you cannot say every Driver is a Truck Driver.
Where
Driver -Parent
Truck Driver - Child.
Animal an = new Dog(); //1. why can animal store a dog but not a dog store an animal
You ordered for an Animal and the shop keeper gave a Dog for you and you are happy since Dog is an Animal.
Dog do = (Dog) new Animal(); //2. Dog has the behavior of an Animal so why explicit downcast
You are asking for a Dog and the shop keeper gave an Animal to you. So it is so obvious that you check that the Animal is a Dog or not. Isn't you ?? Or you just assume that you got a Dog ?
Think.

In java references are used. Suppose we have below classes
class A{
Integer a1;
public A(){
// a1 is initialized
}
public void baseFeature(){
super.baseFeature();
// some extra code
}
}
and
class B extends A{
Integer b1;
Integer b2;
public B(){
super();
// b1 , b2 are initialized
}
#Override
public void baseFeature(){
super.baseFeature();
// some extra code
}
public void extraFeature(){
// some new features not in base class
}
}
Below all 3 statements are valid
A a = new A();
B b = new B();
A b1 = new B();
In java references are used to refer to the objects kept in Heap.
A reference of type A should not be considered as if it can not hold the objects which have more memory required than an object of class A. Its the references and not the objects holders.
In case of sub type object creation, Constructor call follows : Parent-constructor call followed by constructor call of the actual class whose object is being created.
Sub class object can be said to be having features at-least as much as the Parent type has.
A b = new B() has no confusion, as object of B has all the features of its parent.
Sub class object has all the features as defined in its parent, so any parent class method can be called on the object of sub class
Sub classes can have much more features, which parent class does not have, so calling a method of sub class on object of parent will lead to problems.
Suppose In Java B a = new A() is valid then if a.extraFeature() is invoked then it is obvious of an error.
This is prevented by compile time error. If in case downcasting is needed, then the programmer must do it with extra care. This is the intention of compile time error. Below cases down-casting would not lead to issues but the onus is on the programmer to see if situation is of this kind or not.
public void acceptChild(Child c){
c.extraMethodNotWithParent();
}
Parent p = new Child();
acceptChild((Child)p);
Here programmer is given compile time warning if down-casting is not done. Programmer can have a look and can see if the actual object is really of sub class type then he/she can do explicit down-casting. Thus issues will only come if the programmer has not taken care.

All the replies here help. I was confused.
Removing all the chains in my brain, if I simply think, it now looks like:
Parent can hold subtypes.
You mean thats the benefit of polymorphism and how its achieved.
Child types can hold parent but need explicit downcast.
Since polymorphism is allowed, this downcast is a safeguard. The compiler is asked to trust that the Animal in code is actually going to be a Dog instance that the Dog type wants to hold.

This is because inheritance is specialization, when you inherit a class T, the child class S is a specialization of T, for that Java don't need a cast, but T can have many childs, S' inherits T, S' too, so here if you have an object of S and its referenced as T and you want to get your origin type again, you should make a cast to S and Java check the type at runtime.
an example :
A man and a woman are humans, but a human is a man or woman.
Man man = new Man();
Human human = man //Legal.
Man man2 = (Man) humain; //Legal
Woman human = (Woman) humain; //Error, Java can't cast the humain to Woman, because its declared originaly as Man.
If Java is sure made the cast implecitly, if not, it reports it and don't decide in your place, This check is made at runtime.

Why is overriding in JAVA working somewhat differently that from C++?

I have some background in C++ and know some Java too (apparently far from enough).
When I see overriding behavior in Java or C++, it does not seem to differ much. Given below example in JAVA:
class Animal{
public void move(){
System.out.println("Animals can move");
}
}
class Dog extends Animal{
public void move(){
System.out.println("Dogs can walk and run");
}
}
public class TestDog{
public static void main(String args[]){
Animal a = new Animal(); // Animal reference and object
Animal b = new Dog(); // Animal reference but Dog object
a.move();// runs the method in Animal class
b.move();//Runs the method in Dog class
}
}
In Java, you use a base class reference, in C++ you use a base class pointer, and depend on the type of instance it points to (a base class object instance or a subclass instance), you can achieve polymorphism.
The above is based on you call the instance method using a base class reference or pointer, right?
Now I see this example in Java.
What is the order of the Constructors in this Java Code?
Basically it says if a base class function is overriden, then in the process of creating a subclass object, even the base class initialization portion will be affected. See below explanation I copied from above link:
new Son()
=>
Son._init
=> first every constructor calls super()
Father._init
Object._init
who() => is overridden, so prints "son" !!!!!
tell(name) => name is private, so cannot be overridden => "father"
who() => "son"
tell(name) => "son"
Why should this happen? I mean does this conform to how polymorphism should be use? When making base class portion of initialization, why use overrided function from subclass?
In Java doc http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5, I only find this:
"Unlike C++, the Java programming language does not specify altered rules for method dispatch during the creation of a new class instance. If methods are invoked that are overridden in subclasses in the object being initialized, then these overriding methods are used, even before the new object is completely initialized. "
But I don't know the reason behind it, and it feels strange.
Any thoughts?

This is one of the extremely rare cases where C++ is trying to protect you from shooting yourself in the foot more than Java does. (Or at least it has the noble intention to do so.)
You are very likely to shoot yourself in the foot in any language if you try invoking an overridable (virtual) method M of your base class B from within the constructor of B. That's because M is likely to be overridden in derived class D, but at the moment that B is being constructed, D has not been constructed yet. So, D.M is being invoked before the constructor of D has been invoked. That can spell disaster.
So, Java simply allows this to happen, use at your own risk. (If you have sufficient warnings enabled, your compiler will tell you that you are living life dangerously.)
C++ does not prohibit this either, but it slightly changes its behaviour so as to contain the damage, so to speak: when you invoke a virtual method from within a constructor, it does not really invoke it as a virtual method, (with a VMT lookup,) but it invokes it directly, as a non-virtual method.
(Either that, or from within the constructor of B it simply uses class B's VMT instead of D's VMT. Which, come to think of it now, makes sense. But I am not sure about that, it has been a long time since I last troubleshot this behaviour of C++.)

Polymorphism vs Inheritance

Suppose I have two classes: Animal and Dog. Dog is a subclass of Animal. I do the following code:
Animal a = new Dog();
Now I can call methods of the Dog class through the a variable.
But my question is this: if I can call all of Animal's methods through the Dog objects (inheritance) than why should I use the polymorphism principle? I can just declare:
Dog d = new Dog();
With this declaration can use all of Animal's methods and Dog methods. So why use polymorphism? Thank you very much for your answer.

In Java, the concepts of polymorphism and inheritance are "welded together"; in general, it does not have to be that way:
Polymorphism lets you call methods of a class without knowing the exact type of the class
Inheritance lets derived classes share interfaces and code of their base classes
There are languages where inheritance is decoupled from polymorphism:
In C++ you can inherit a class without producing polymorphic behavior (i.e. do not mark functions in the base class with virtual)
In Objective C you can implement a method on an unrelated class, and call it from a place that knows only the signature of the method.
Going back to Java, the reason to use polymorphism is decoupling your code from the details of the implementation of its counter-parties: for example, if you can write a method Feed(Animal animal) that works for all sorts of animals, the method would remain applicable when you add more subclasses or implementations of the Animal. This is in contrast to a Feed(Dog dog) method, that would be tightly coupled to dogs.
As far as the
Dog d = new Dog();
declaration goes, there is no general reason to avoid this if you know that the rest of your method deals specifically with dogs. However, in many cases the later is not the case: for example, your class or your methods would often be insensitive to the exact implementation, for example
List<Integer> numbers = new ArrayList<Integer>();
In cases like that, you can replace new ArrayList<Integer>() with new LinkedList<Integer>(), and know that your code is going to compile. In contrast, had your numbers list been declared as ArrayList<Integer> numbers, such switchover may not have been a certainty.
This is called "programming to an interface". There is a very good answer on Stack Overflow explaining it.

You can have other implementations of the Animal class, such as Cat. Then you can say
Animal a = new Dog();
Animal b = new Cat();
You can call methods of the Animal class without caring which implementation it really is, and polymorphism will call the correct method. E.g.
a.speak(); // "Woof"
b.speak(); // "Meow"
Really, it's not "Polymorphism vs Inheritance" but "Polymorphism using Inheritance".

Polymorphism allows you to write a method that works for any Animal:
public void pet(Animal animal) {
...
}
This method would accept Dog, Cat, etc, including subclasses of Animal that are yet to be written.
If the method were to take Dog, it would not work for Cat etc.

If you are certain that it will always be a dog there is no reason for it. You might aswell use Dog d = new Dog(); as you described. But let's say you used a method instead of a constructor. The method returned an animal and you wouldn't know which implementation of animal you would get. You would still be able to use the same methods on the animal (even if it's a Dog, Elephant cat etc).
For extensibility purposes inheritance simplifies things. When you want to create an elephant or cat which also share some animal methods, You can easily get those by having animal as super class.

Normally the question you've asked is more similar to Inheritance vs Composition :) More "real life" example of why it's good to use polymorphism is for example usage of strategy design pattern. You can have many TaxPolicy implementation: UsaTaxPolicy, CanadaTaxPolicy, EuTaxPolicy, etc. If you have method calculateFinalPrice, which have to also calculate tax, then you inject the proper implementation and good calculation is executed, no matter you've passed Usa, Canada or Eu implementation.

inheritance is the dynamic polymorphism. I mean when you remove inheritance you can not override anymore.

Use of base class object by child class reference - java

What is the use of creating base class object using child class reference in Java

If I understand correctly, you mean:
class Parent {
...
}
class Child extends Parent {
...
}
Parent p = new Child ();
There are many reasons:
Flexibility: you can use Parent as a parameter type, and pass any subclass (i.e. Child and other) as this parameter.
Polymorphism: You can override Parent method in several Child classes and use them in turn where Parent object required (like in Strategy pattern)
If you're working on some public API you can make Parent class public and visible to everyone but all Childs can be invisible to outer users. It can make your API more narrow. Good example is Collections API. There are 32 implementations (i.e. Childs) which are used implicitely, but only a few public interfaces. You can obtain synchronized, unmodifiable and other collections through Collection (i.e. Parent) interface not knowing implementation details.

Animal myAnimal1 = new Dog();
Animal myAnimal2 = new Cat();
Animal myAnimal3 = new Horse();
Suppose Animal has a method called getAnimalSound() and Dog, Cat, Horse all override that method according to them. Now, this code is very extensible, your API can have just one method getAnimalSound() to indicate sound of any kind of an animal, in tern each animal class has already implemented their own version of getAnimalSound()
System.out.println(getAnimalSound(myAnimal1)); //runtime finds animal1 is dog, prints Bark
System.out.println(getAnimalSound(myAnimal2));//runtime finds animal2 is cat, prints Meow
System.out.println(getAnimalSound(myAnimal3));//runtime finds animal3 is horse, prints Niih
As you can see one Method getAnimalSound() is the standard API, but we achieved so much of extensibility.

If you mean things like
List<String> list = new ArrayList<String>()
then you are not actually creating an instance of the superclass. You are only telling the user to handle it as if it was one. The point is that you often don't need to know the exact implementation that was chosen and wish to retain the ability to change the implementation. Hence you only tell a user of an API that something is a List and if your algorithm requires it, you can change the implementation to use a LinkedList instead, without changing the API.