It All Starts with Classification

The need to classify things according to their proper place has been a part of the human evolution. I cannot think of another living creature on this planet that has the same yearning. Aristotle, the philosopher-mentor of Alexander the Great (my ancient namesake), created an effective method of classifying animals. Though crude and simple, it made sense. His technique was to divide the animal kingdom into smaller groups based on a certain feature. The result is a taxonomy of animals which shows how they are all similar at a certain level, and how they gradually branch out differently as they progress downwards. It seems tedious, but everything has to start somewhere.

How does this at all relate to the title on polymorphism then? Polymorphic methods get to be polymorphic because they respond to method calls of methods that have similar names but different behaviors.

This being the case, two aspects immediately come to mind: overriding and overloading.

Overriding

Overriding is creating a different implementation of an existing method with the same name in its base class. Knowledge of how to override a method is easy. But knowing when to allow a method to be overridden is much more challenging. Creating a virtual or abstract method which you know will eventually be overridden, is the next best thing to seeing into the future (deciding on an interface though requires thetan level 9 clairvoyance). This is definitely where our friend Aristotle the “Animal Sorter” can help us. Determining which methods you should declare virtual or abstract has more to do with how your classes are related through inheritance rather than which methods are common. A perfect example would be having an abstract “eat” method for our animal base class. All animals eat, but in different ways. At some level they will start eating the same way, but the way they eat is determined by how the deriving class is related to its base class.

Overloading

Overloading has absolutely nothing to do with Aristotle or animals. Overloading is used when you want to have the same method name, but with a different signature, while trying to do the same thing. How then can you say that, an overloaded method is polymorphic when in fact it is doing the same thing? Wouldn’t a “WriteLine” method overload that behaves differently based on the number of parameters passed, be weird? So does this mean overloaded methods cannot be polymorphic? The answer is NO, overloaded methods CAN be polymorphic. Operators are in fact overloaded. Whenever you perform an assignment using the “=” operator, it actually chooses which “AssignValue” overload method is called, based on the parameters you give. The same way you can add an integer “1 + 1” and a string “a” + “b” with the same operator. This type of overloading is actually called Ad-hoc polymorphism.

Other Types of Polymorphism

There are actually other types of polymorphism which are not usually discussed but are available in .NET. Sub-type polymorphism is when a super-type is used as a replacement parameter for its sub-type. Which is why passing a “bird” object which is a sub-type of the “animal” class, to a method accepting an “animal” parameter, which is a super-type of “bird” class is acceptable.

Another type of polymorphism that is available in .NET is parametric polymorphism. When a method accepts a list of parameters that are to be of a similar type based on a certain constraint, it can be said that the method is now polymorphic because the data types passed are polymorphic. Simply put, as long as you can keep appending parameter data on a method that accepts parameters that are constrained to be similar, it can be argued that the method is polymorphic – because the parameters are polymorphic. And you can easily do this using Generics.