Overridding Sufficient for Polymorphism?
All,
This is probably an elementary question; however, as I never had a formal CS education, I was wondering what the actual, correct answer is.
Would overridding a concrete (implemented) method in a superclass within a subclass constitute (or provide) polymorphism? In Java code:
class FooAncestor{
publicvoid bar(){};
}
class FooDescendantextends FooAncestor{
publicvoid bar(){ super.bar()};
}
Has the 'bar()' method become polymorphic? My understanding is that a combination of inheritance (either interface or class) and the implementation of an abstract method (either interface or abstract class) gives you polymorphism.
However, is the requirement that the method overridden (or implemented) be abstract a valid requirement to have polymorphism. Or is overridding alone sufficient for polymorphism?
Thanks!
- Saish
[1351 byte] By [
Saisha] at [2007-10-2 9:29:03]
And on a related note. Would overloading a method within the same class constitute polymorphism? - Saish
Saisha at 2007-7-16 23:35:37 >
Though not the best example, I would have to say that overriding could provide polymorphic behaviour.As for overloading, I will refer to wikipedia and the term "Ad-hoc Polymorphism": http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
Liggya at 2007-7-16 23:35:37 >
In Java, polymorphism generally means that the version of the method that is executed is determined by the type of the Object instance. Using that definition, yes, overloading the concrete method is polymorphic.
In terms of the langugage defintion and the JVM spec, whether the overriden method is concrete or not is unimportant so saying the overriden method must be abstract would create a distinction without a difference IMO.
Also, consider classes A <- B <- C with method foo declared on A as abstract and on B and C as concrete. If the parent must be abstract, is C.foo polymorphic? If not, changing the definition of C to extend A directly makes C.foo polymorphic? Again that would be a meaningless (and useless) distinction.
> Would overridding a concrete (implemented) method in
> a superclass within a subclass constitute (or
> provide) polymorphism?
I think yes, it would. Personally, I consider not only the implemented method in the subclass(es) a demonstration of polymorphism, but the implemented method in a superclass, too! Because the principle of polymorphism means that if you execute a method of an object, you are not able to know exactly which behaviour this method will have (the method can have many forms, many behaviours), but you can be sure that the behaviour is always correct, is always what you expect. I think this definition makes sense even considering the method in a superclass.
Just to clarify more:
class ParentClass {
public void method() {
System.out.println("in ParentClass");
}
}
class ChildClassOne extends ParentClass {
public void method() {
System.out.println("in ChildClassOne");
}
}
class ChildClassTwo extends ParentClass {
public void method() {
System.out.println("in ChildClassTwo");
}
}
public class TheClass {
public static void main(String[] args) {
ParentClass objParent = new ParentClass();
ParentClass objChildOne = new ChildClassOne();
ParentClass objChildTwo = new ChildClassTwo();
ParentClass[] theArray = new ParentClass[3];
theArray[1] = objParent;
theArray[2] = objChildOne;
theArray[3] = objChildTwo;
for (int i=0; i<theArray.length ; i++) {
//You know that this array contains
//ParentClass objects,
//but you are not able to know
//exactly which method will be executed.
//Notice that even the method in the ParentClass
//is one of the methods that you don磘 know.
//This is the demonstration of polymorphism.
theArray[i].method();
}
}
}
> Has the 'bar()' method become polymorphic?
Yes, it has.
> My understanding is that a combination of inheritance
> (either interface or class) and the implementation of
> an abstract method (either interface or abstract
> class) gives you polymorphism.
My example shows that non-abstract methods implemented in the subclasses can demonstrate polymorphism. And even the implemented method itself in the superclass, can be considered when you want to demonstrate polymorphism. Therefore, this is a clear proof that the method doesn磘 need to be abstract.
> Or is overridding
> alone sufficient for polymorphism?
Yes, overriding alone is sufficient for that.
Thanks Liggy, Dubwai and Marceleo. I started thinking again about this last night (this is what I do when the power goes out). I agree that it is polymorphism. However, perhaps there is another distinction:
Overridding and overloading provide procedural polymorphism
Implementing an abstract method provides object-oriented polymorphism
I started to think this way in terms of C versus C++. Overridding and overloading at a method level existed in C, prior to C++, as procedural polymorphism. With the introduction of C++, both objects and abstract methods were introduced, allowing for object-oriented polymorphism.
Well, maybe even that is not a valid distinction. It just seems to me that the two are different types of polymorphism. Maybe I am just too far off on a tangent. I digress.
- Saish
Saisha at 2007-7-16 23:35:37 >
> I started to think this way in terms of C versus C++.> Overridding and overloading at a method level> l existed in C, prior to C++, as procedural> polymorphism. Over-ri-loa-ding in C? How so?
Very easy:void print(double);void print(long);- Saish
Saisha at 2007-7-16 23:35:37 >
> Very easy:
>
> > void print(double);
> void print(long);
>
>
> - Saish
What malfunctioning C compiler accepts that!?
From Steele, Harbison Chapter 4.2.5:
It is incalid to make two declarations of the same name (in the same overloading class) in the same block or at the top level. Such declarations are said to conflict.
> incalidObviously, the 'v' button on my keyboard must be broken.
I can only refer you to Stroustrup. Second 7.4 "Overloaded Function Names" (pg. 149). This occurs prior to any dicussion of C++ concepts. Thus, my assumption is that what I posted (actually taken right from the same page) is valid C syntax.- Saish
Saisha at 2007-7-16 23:35:37 >
Ah. Dammit. I forgot about that difference. My apologies and my bad. Appears overloading IS in fact C++ and not C.- Saish
Saisha at 2007-7-16 23:35:37 >
> Implementing an abstract method provides
> object-oriented polymorphism
I think the "beauty" of abstract methods usage comes from the fact that, sometimes, when you are designing, writing the implementation of some method inside the parent class simply doesn磘 make sense. Example:
/**
* This class is the parent class of all kinds of printers.
* Are you able to provide an implementation of print() method
* in this Printer parent class? I don磘 think so, because
* you are not able to guess a common behaviour of this method
* for all the printers.
*
* Therefore, in designing, it would make much more sense if you simply
* didn磘 provide an implementation for this method, because
* providing an implementation simply wouldn磘 be useful.
**/
abstract class Printer {
public abstract void print();
}
But, let磗 assume that you really want to provide an implementation for the print() method above, inside that Printer parent abstract class. Which kind of design problem will happen, probably? All the programmers who will use your print() method, by extending your Print parent abstract class, all these programmers probably will override your method. So, where will the importance of your implementation for the print() method inside the parent class be? This importance simply wouldn磘 exist. That磗 why abstract methods are really important.
But, I磛e just given aditional informations above. That is not specifically related with what you said. You are saying that abstract methods, in certain way, provide object-oriented polymorphism...Well, I was thinking about your affirmative, and the only insight I could have is the fact that, in a certain way, abstract methods can estimulate programmers to create subclasses, and therefore, you will see the overriding polymorphism in action more often. Although, I think you only have to create abstract classes and abstract methods if it really makes sense, like in my example above, with the Printer class.
I guess here is another reason I do not believe overridding is 'true' polymorphism: the definition of overridding is arbitrary. For example, I could have a language where a method name must be unique. Thus, the following could be construed as 'overridding':
public void printDouble(double);
public void printString(string);
I fail to see how this is materially different from a language, like Java, where method name and parameter signature must be unique:
public void print(double);
public void print(String);
Finally, in C++ or other languages, the above plus return type must be unique:
public double get();
public String get();
So, overridding in the first case might not even exist. Overridding in the second and third cases obviously exist. However, given the concept is the same and that the only things that are changing are uniqueness requirements for a given method, it seems to me this is a weak form of polymorphism.
- Saish
Saisha at 2007-7-16 23:35:37 >
> I guess here is another reason I do not believe
> overridding is 'true' polymorphism: the definition
> of overridding is arbitrary. For example, I could
> have a language where a method name must be unique.
> Thus, the following could be construed as
> 'overridding':
sure but your definition of what is 'true polymorphism' is jsut as arbitrary. I agree that method overriding in Java is not what I consider polymorphism but you asked for a definition from a CS perspective, which includes overriding.
One other thing. In languages that support double dispatch, overriding is polymorphic in the way you are defining it.
Sorry, the above I was trying to demonstrate was both overridding and overloading.
And thanks Dubwai. I agree that the technical (or if I may be so bold, the orthodox) explanation is correct. Perhaps there should be additional qualifiers to using the word polymorphic then? Perhaps one could say "OO polymorphism" to distinguish between runtime and compile-time evaluation of polymorphism?
Sorry, inventing new terms that will probably never generally be used. But no harm in trying....:^)
- Saish
Saisha at 2007-7-20 20:14:37 >
