“Polymorphism: How Code Shape-Shifts for Flexibility”

You get the best of both worlds: a consistent way of doing things, but room for individual flair.

What Is Polymorphism Anyway?

In simple terms, polymorphism means “many shapes.” It’s a term we borrow from biology, where it’s used to describe species that can appear in different forms.

This idea finds its way into coding, too. In programming, it allows stuff like methods and references to behave in more than one way.

Who Gets to Be Polymorphic? Or Who Can Morph ?

In the programming world, especially in Java, this “shape-shifting” ability applies to reference variables and methods. They can take on different roles. A single reference can point to its own type or any of its subtypes. Likewise, methods can have different behaviors depending on the class they’re in.

How Do We Get This “Multiple Behavior” Thing?

One word: Override. By modifying a parent method in a child class, you bring in this flexibility, Think of it as customization. A child class can take a method from its parent class and adjust it, all while keeping its original outline.

Picking Out the Essentials:

When there’s method overriding, you naturally wonder: which method gets executed? This very question underpins the essence of polymorphism. This question is at the heart of polymorphism. Essentially, asking ‘which method?’ is another way of asking ‘which behavior? The dilemma of ‘which method to execute’ highlights the principle of exhibiting multiple behaviors. Since methods determine the behavior of an object, they encapsulate the actions an object can perform. Thus, when we talk about the ‘multiple forms’ or ‘multiple behaviors’ central to polymorphism, we are essentially referring to these varying method implementations.”

If there’s no override, there’s no question:

• If a method can be overridden (it’s neither static nor final), the JVM looks at the object’s actual runtime type to decide which version to run.
• If a method can’t be overridden,there’s no need for the JVM to mull over which version to execute. This decision is made at compile-time

Breaking It Down:

Let’s paint a picture:

Static Method:

They belong to the class itself and not to any specific instance. These methods can’t be overridden, so the JVM doesn’t have to make any runtime decisions. It simply runs the static method as is. The Java Virtual Machine (JVM) doesn’t even have to think twice; it just goes ahead and uses them as they are.

Suppose you have a static method myStaticMethod in a class Parent and you also have a static method with the same name in a subclass Child. If you have a reference of type Parent pointing to an object of type Child, calling myStaticMethod on that reference will call the method from the Parent class, not the Child class. No exceptions.

Non-Static Methods

For non-static methods, the JVM has some work to do. It uses dynamic method dispatch to figure out which version of the method to run, based on the object’s actual runtime type. It climbs up the inheritance tree until it finds a method that fits the bill.

. Final Method: Final methods can’t be overridden. These methods aren’t open for changes. So, the JVM will always use the version from the reference’s type, no matter the object’s type.

Therefore, if you call a final method on a reference, the version in the compile-time type of the reference will be the one that gets executed, regardless of the object’s actual runtime type.

In both scenarios, because the method can’t be overridden, there’s no need for the JVM to look at the object’s runtime type to decide which version of the method to execute. It will directly execute the method that is associated with the compile-time type of the reference.

Or in another word, we can say normally the method in the reference type is being executed unless it can be overriden, it doesn’t matter or it is not important the reference shows which object or what its actual type, first top of checklist if it can be overriden or not

If there’s no override, there’s no question.

Conclusion

Polymorphism boils down to the ability to override methods. If a method can’t be overridden, there’s no dilemma; the JVM knows what to do. But if it can, the JVM has to think on its feet to decide which version to run. This dynamism is what makes polymorphism so compelling.

The Bottom Line

Override equals flexibility. If you can override a method, you get multiple behaviors. But if you can’t, then you’re locked into the default behavior, which isn’t necessarily a bad thing.

No Override, No Problem for the JVM

So, the key to polymorphism is overriding. If a method can’t be overridden — like static or final ones — Java sticks with the parent class’s version. Simply put, Java first checks if a method can be overridden. If yes, it looks at the actual object; if not, it goes with the default.

Note:”I am not the author of the articles I share; they are written by GPT. However, I collaborated with GPT during the article creation process.

When sharing articles, my primary goal is their comprehensibility. I select specific details and examples in the content believing they will enhance clarity. I aim to highlight the aspects I believe will illuminate the subject matter.

Believing that highlighting these points would clarify the topic, I provided these specifics to GPT. Then GPT undertook the task of crafting the text and refining it grammatically based on this input.”