Polymorphism was one of those programming words that used to sound scary the first time I ever heard of it. It literally means “many forms” but in OOP, it’s not as scary-sounding as it is. It’s basically when the same method or function can be something different based on what object it’s being called from. As soon as I started reading over some examples, it made a lot more sense.
Think of it like this: an individual might be a class student, a home sibling, and maybe a work employee. Same person, various role depending on context. In programming, polymorphism enables us to do one thing with one function that changes its behavior depending on the object.
There are two main forms of polymorphism. Compile-time polymorphism (or static) is solved before the program ever runs. That generally happens with method overloading, where you have multiple versions on the same method name with different parameters. The compiler figures out which one to invoke. Operator overloading is another example, like using “+” for numbers and strings too.
Then there is runtime polymorphism (dynamic), resolved as the program is running. That is what happens with method overriding. A case in point is a parent class Shape that has a method draw(). Subclasses such as Circle and Square override draw() to do something else. When you call draw(), the program picks one that matches the actual object.
First of all, I used to confuse this with inheritance. They definitely go hand in hand, but they are not one and the same. Inheritance is when you are copying another class’s code. Polymorphism is when you have the same method name but have different action.
A lot of people also think that using polymorphism, especially the runtime kind, makes programs really slow. I used to believe that too, but it turns out that’s not really the case anymore. Modern compilers are built to handle this kind of thing quickly with tricks like virtual tables, so the performance hit is tiny. The trade-off is worth it because you get cleaner code and way more flexibility, so worrying about speed here feels kind of outdated.
I’ve read about this and it struck me how many times I’ve made my own code overly complicated. In Java, for example, I used to create a whole bunch of methods with unique names when I could have done overloading. I also blocked overriding in subclasses because I believed that it would be slow. Now I know that not just is that fine, it’s the correct thing to do most of the time.
In the future, I’d like to use polymorphism more intentionally, especially in my Android applications. It’ll be a tremendous assistance if new functionality is introduced in the future because I won’t need to begin anew. That, to me, is the beauty of OOP, it’s not just about making things function, but making them simpler to maintain and extend in the long run.
Resources:
https://www.cincom.com/blog/smalltalk/polymorphism-in-object-oriented-programming/
Maria Delia 