Polymorphisms

[Saad Zahoor]

Question : As far as i know that polymorphism consists of two parts 1.Method overLoading 2.Method overRiding  .. if there is anyThing more please let me know  Because i saw on tutorials and they are doing , I don't know what equal child class with the parent class . Totally confusing !!

[praveen kumaar]

The first thing to understand is what is Polymorphism:
In a nutshell,polymorphism means ability of some type to show different behaviour(different circumstances).for example in java method overloading(also called as Ad hoc polymorphism) provides a way to design a method(or constructor,it does not have return type though) with the same name(as one is already present) but with different signature(it includes the argument as well as return type,their are various permutations for this implementation)lets say for example you have a method named "A" having the return type "B" and only one argument having type "C".if you want to overload this method you can:
→only change the number of arguments.
→change the no of arguments(we can also change it's type) as well as return type.
→change the type of a argument.
→change the type of argument as well as return type.
keeping the number of arguments and type same and changing the return type will produce the compile time error as it will be ambiguous to determine which one's to invoke.
The next type of polymorphism is the subtyping(also called as Run time Polymorphism in java).this type of polymorphism helps a variable of type SuperClass to reference a object of type SubClass.in java this facility helps to have a different behavior of a instance method(inherited from super class) in a sub class(in this case the name as well as signature remains the same,don't forgot the covariant types though,the resulting method is called overriden).
Apart from these two type their is also a third type of polymorphism called generics(yes we have this feature in java).what it does is it provides a compile time safety(probably can be called compile time polymorphism).here we can use a parameter(which is not specifically mentioned) in our code and compiler will infer this type accordingly we provide it during when we are using that code in our program.
Have a look at this code:

public class Polymorphism<T> {
 void print(T arg) {
  System.out.println(arg);
 }

 void print(T arg_1,T arg_2) {
  System.out.println(arg_1.toString()+" "+arg_2.toString());
 }

 void print(T...arg) {
  for(T t:arg)
   System.out.print(t+" ");
  System.out.println();
 }
}

public class PolymorphismExtended<T> extends Polymorphism<T> {
 @Override
 void print(T arg) {
  System.out.println("Overriden Implementation: "+arg);
 }

 @Override
 void print(T arg_1,T arg_2) {
  System.out.println("Overriden Implementation: "+arg_1+" "+arg_2);
 }

 @Override
 void print(T...arg) {
  System.out.print("Overriden Implementation: ");
  for(T t:arg)
   System.out.print(t+" ");
  System.out.println();
 }

 public static void main(String...args) {
  Polymorphism<String> poly    = new Polymorphism<>();
  Polymorphism<String> polyext = new PolymorphismExtended<>();
  poly.print("hi folks !");
  poly.print("hi","folks !");
  poly.print("hi","folks","!");
  polyext.print("hi folks !");
  polyext.print("hi","folks !");
  polyext.print("hi","folks","!");
 }
}

Output:

hi folks !
hi folks !
hi folks !
Overriden Implementation: hi folks !
Overriden Implementation: hi folks !
Overriden Implementation: hi folks !

At line 37 and 38 we have use the type String so compiler is smart enough to interpret the type as a String where ever we have used T in the declaration.
At line 38 you can see i have use the reference type Polymorphism,though it is referering to object of type PolymorphismExtended,this polymorphism will help in invoking the overriden version of method on this object(if anywhere called).
Now take a look at the method print in both the Polymorphism and PolymorphismExtended class we have diffrent signature for the 3 methods so is overloaded but if you will see in the PolymorphismExtended i have used the override annotation because these 3 methods are overriden version of the 3 methods available in superclass(compare the name and signature of the respective methods in both the classes you will find it's same that's why they are called overriden).

Hope it helps!

Kind Regards,
Praveen.

[Dana Ucaed]

Very good explanation!!!

[Junilu Lacar]

praveen kumaar wrote:the same name(as one is already present) but with different signature(it includes the argument as well as return type,their are various permutations for this implementation)

This is actually a contradiction. The method's return type is not part of its signature.

This page http://docs.oracle.com/javase/tutorial/java/javaOO/methods.html defines what makes up a method signature: the method name and its parameter types. It should also be noted that when there are multiple parameters, the order of the parameter types is also a consideration.  

By definition, overloading means that the method name is the same but the parameter types (or ordering of those types) is/are different. Overriding means that the methods have exactly the same signature (name, parameter types/ordering of the types) except the methods exist in classes that have a superclass-subclass relationship. Method overloading can exist within the same class or between classes that have a superclass-subclass relationship.

To illustrate why a method's return type is not a part of its signature, consider the following:

public int doSomething(String s) {...}

public String doSomething(String s) {...}

How would the Java compiler know which method to call given this code:

doSomething("Which one?");

The compiler will be unable to deterministically figure out which version of doSomething(String) to call.

Now, consider this:

public void doSomething(int i, int j) {...}

public void doSomething(int j, int i) {...}

To the Java compiler, these two methods have exactly the same signature. When it comes to method signatures and overloading, only the parameter types and order is relevant; the names of the parameters are irrelevant.

The following illustrates legally overloaded methods:

public void doSomething(String s, int i) {...}
public void doSomething(String s) {...} // different parameter types
public void doSomething(int i, String s) {...} // same parameter types but different order

[Campbell Ritchie]

Although you sometimes hear terms like, “compile‑time polymorphism,” I do not believe that overridingoverloading constitutes polymorphism at all. It means that the behaviour of two objects at runtime might be different because their runtime type is different even if their compile‑time types (=declared types) are the same.
In Java® that means overridden accessible (not private) non‑final instance methods. And nothing else.

[praveen kumaar]

Campbell Ritchie wrote:Although you sometimes hear terms like, “compile‑time polymorphism,” I do not believe that overridingoverloading constitutes polymorphism at all. It means that the behaviour of two objects at runtime might be different because their runtime type is different even if their compile‑time types (=declared types) are the same.
In Java® that means overridden accessible (not private) non‑final instance methods. And nothing else.

Campbell,
i think you are misinterpreting the 2 different things.the reason this is less intuitive to you can be you are thinking about the polymorphism in regard of runtime polymorphism only.though i would agree with you that their is not any term like compile time polymorphism(oficially,in java,however i am not sure about other languages).but i will not agree with you for your views on  polymorphism of the overloaded methods(called as Ad hoc polymorphism in computer science,but again we don't have this term in java).this type of polymorphism can be applied to functions(called as methods in java and luckily we have the implementation of this polymorphism in java).
Let's see an example:

class Polymorphism {
 void print(String arg) {
  System.out.print(arg);
 }
 
 void print(String arg_1,int arg_2) {
  print(arg_1);
  print(" ");
  print(""+arg_2);
 }

 <T extends Number> void print(T arg) {
  print(""+arg);
 }
}

class PolymorphismExtended extends Polymorphism {
 @Override
 void print(String arg_1,int arg_2) {
  print("Extended: ");
  print(arg_1);
  print(" ");
  print(arg_2);
 }
 
 @Override
 <T extends Number> void print(T arg) {
  print("Extended: ");
  print(""+arg);
 }

 public static void main(String...args) {
  Polymorphism poly = new PolymorphismExtended();
  poly.print("#Hi folks-",1);
  poly.print(System.lineSeparator());
  poly.print(2);
  poly.print(System.lineSeparator());
 }
}

If you would see the line 35 and 36,compiler is playing a role in polymorphism(ad-hoc and generic) here.compiler knows that the type of an object is Polymorphism here so it would place the call at line 35 as the call to the method having signature print(String,int) in class Polymorphism[yes the compiler will put the call for the method present in class Polymorphism] but along with the effect of run-time polymorphism(also called as Subtyping polymorphism) during run-time,the method actually invoked would be the one overriden(present in PolymorphismExtended).means the call at line 35 is due to the effect of both the overloading(ad-hoc polymorphism) and the runtime polymorphism and because it was the compiler who finds the correct method(amongst the overloaded) it was not a bad idea to call this type of polymorphism as compile-time polymorphism.
now come at line 36,here again compiler has a very great role and their is a third kind of polymorphism is actually going on here called as Generics in java(but generally it is also called Parametric polymorphism).here it was compiler who will infer the T as Integer at line 36 along with finding the proper method(accordingly with the signature-ad hoc polymorphism).and in fact at this line we have all the 3 types of polymorphism in action:
→compiler is playing a role in ad hoc polymorphism and parametric polymorphism,it will detect the proper call and infer the parameter T.
→jvm will play a role in run-time polymorphism(by detecting the real type of object at run-time) by calling the overriden version(present in class PolymorphismExtended) of the generic method.
again in my opinion it is not a bad idea to call a parametric polymorphism(generics) as compile-time polymorphism(in java) as compiler is only playing role for it.
for a proof purpose you can see the disassambled code for the main method,here it is:
public static void main(java.lang.String...);    Code:       0: new           #12                 // class PolymorphismExtended       3: dup       4: invokespecial #13                 // Method "<init>":()V       7: astore_1       8: aload_1       9: ldc           #14                 // String #Hi folks-      11: iconst_1      12: invokevirtual #15                 // Method Polymorphism.print:(Ljava/lang/String;I)V      15: aload_1      16: invokestatic  #16                 // Method java/lang/System.lineSeparator:()Ljava/lang/String;      19: invokevirtual #17                 // Method Polymorphism.print:(Ljava/lang/String;)V      22: aload_1      23: iconst_2      24: invokestatic  #18                 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;      27: invokevirtual #19                 // Method Polymorphism.print:(Ljava/lang/Number;)V      30: aload_1      31: invokestatic  #16                 // Method java/lang/System.lineSeparator:()Ljava/lang/String;      34: invokevirtual #17                 // Method Polymorphism.print:(Ljava/lang/String;)V      37: returnlook at the line 10(marked as 12 inside bytecode),there are 2 things invokevirtual which means the virtual method invocation(the runtime polymorphism) and the next thing is the method written as "Method Polymorphism.print:(Ljava/lang/String;I)V" which shows compiler opts the method with signature print(String,int) having void as a return type and i can read the line as "virtual method invocation of the method present in class Polymorphism with signature print(String,int)V."V is for void.so it's easy to say here we have the combined effect of the ad hoc and the runtime polymorphism.
now come at line 24 and 27.you can easily see there,compiler is inferring the T as Integer and then at next line we have again the effect of combined poymorphism(of the 2 mentioned above) in action.

and @Junilu thanks for the correction for my previous post regarding signature.i am glad that we have members like you for the proper guidance where ever we are wrong.

Kind regards,
Praveen.

[Campbell Ritchie]

What was described as ad hoc polymorphism in the link you gave me seems to be the same as operator overloading. The name Strachey gave it fifty years ago would appear to have disappeared from people's vocabulary. What you are showing is a combination of polymorphism and method overloading. The generic method you are calling shows a combination of two phenomena, which are occurring at different times and independently of each other. At compile‑time, the <T> version of the overloaded method is called. The only T you could get out of an int is Integer, and you made it a bit easier for the compiler by saying <T extends Number>.
At runtime, the virtual machine has to decide whether to use the superclass method or its overridden version. What happens at line 36 is not decided by the compiler but at runtime. Only the behaviour of the overridden method matches my definition of polymorphism, that the behaviour of the program varies with the runtime type of the object the method is called on. The other behaviour is determined by the declared types of the arguments at compile‑time and does not match my definition. I know there are people who talk about compile‑time polymorphism, but I think that is a contradiction in terms.