One instruction, delivered to different objects, produces different but each perfectly appropriate results — without the code giving the instruction needing to know exactly which object it is talking to.

Picture a teacher who says “everyone, please make a sound like your favourite animal.” One child barks. Another meows. Another roars like a lion. Everyone received the exact same instruction, yet everyone responded in their own fitting way — nobody needed a separate, custom instruction for each child. The teacher’s single request was flexible enough to produce many correct, different answers.

That is the whole spirit of polymorphism in programming. It is the idea that a single instruction, given to different objects, can produce different — but each perfectly appropriate — results, without the code giving that instruction needing to know exactly which object it is talking to.

The word itself sounds intimidating mostly because of its Greek origins, but the underlying idea is something everyone already uses instinctively, dozens of times a day, without ever thinking about it in formal terms.

This guide is the third in a small series exploring the core ideas of object-oriented programming, following earlier guides on the four pillars in general and on inheritance specifically. Polymorphism is closely tied to both — it is often described as the payoff that inheritance and shared structure ultimately make possible. Where the earlier guides focused on how classes are built and related to each other, this one focuses on what that structure actually lets a program do once it is in place.

From the Greek poly (many) and morph (form). Many shapes, one underlying identity — a pattern that shows up in biology and chemistry too.

Polymorphism comes from two old Greek words: poly, meaning “many,” and morph, meaning “form” or “shape.” Put together, it simply means “many shapes” or “many forms.” That is a genuinely accurate description of what it does in code: one single action takes on many different, fitting shapes depending on who is carrying it out.

Interestingly, this word is not exclusive to computer programming. Biologists use the very same word to describe something conceptually similar in living things — when a single species naturally occurs in multiple different visible forms, like a butterfly species where some individuals have spotted wings and others have plain ones, all still belonging to the exact same species. Chemists use a related idea too, describing how the same substance can arrange itself into more than one crystal structure. In every one of these fields, the word is pointing at essentially the same underlying pattern: one shared identity, expressed through more than one visible form.

Knowing this shared origin can actually make the programming definition easier to hold onto. Whenever the technical explanation feels slippery, it helps to come back to the plain meaning of the Greek roots: many shapes, one underlying identity. A circle and a square are both, at heart, “a Shape” — just expressed through different, appropriate visual forms. That is really all polymorphism in code is describing, dressed up in more formal language.

The ability of different objects to respond to the same instruction, each in a way that fits their own type — and the caller never needs to know which type it is dealing with.

In more formal programming terms, polymorphism is the ability of different objects to respond to the same instruction, message, or method call, each in a way that fits their own specific type. The code sending the instruction does not need to know, or even care, exactly which specific kind of object is on the receiving end — it simply trusts that each object will handle the request appropriately, in its own way.

This idea leans heavily on two concepts covered in earlier guides in this series: inheritance, which creates families of related classes, and method overriding, which lets each class in that family customise a shared action. Polymorphism is really what makes all of that customisation actually useful in practice — it is the reason a program can treat a whole family of related objects as interchangeable, while still getting correct, specific behaviour out of each one.

There is a subtle but important detail worth calling out here: polymorphism is fundamentally about the caller’s perspective, not the object’s. From the object’s point of view, nothing particularly unusual is happening — a Circle simply knows how to calculate its own area, the same way it always has. What is genuinely special is the perspective of the code making the request: it gets to stay blissfully unaware of exactly which shape it is dealing with, trusting the object on the other end to handle the specifics correctly. That shift in perspective — writing code aimed at “any Shape” rather than “specifically a Circle, or specifically a Square” — is really the whole point.

Without polymorphism, working with a family of related objects becomes clumsy fast — endless chains of “if this type, do this; if that type, do that.”

Without polymorphism, working with a family of related objects becomes clumsy fast. Imagine a program has to move a Bird, a Fish, and a Snake. Without polymorphism, the code would need something like a long chain of checks: “if this is a Bird, make it fly; if this is a Fish, make it swim; if this is a Snake, make it slither.” Every time a new creature type gets added, someone has to remember to go back and update that chain of checks, in every single place it appears throughout the program.

Polymorphism essentially lets a developer write code once, aimed at a general idea — “any Animal,” “any Shape,” “any PaymentMethod” — and trust that it will keep working correctly even as new, specific kinds of Animals, Shapes, or PaymentMethods get added to the program long after that original code was written.

Consider what happens to a real project over months and years without this ability. A shipping app that started out only supporting standard delivery and express delivery might, a year later, need to add same-day delivery, international delivery, and scheduled delivery. Without polymorphism, every single place in the program that calculates a delivery estimate would need to be tracked down and manually updated to handle these new cases. With polymorphism, each new delivery type simply provides its own version of “calculate estimate,” and every existing piece of code that already asks for an estimate keeps working correctly, completely unaware that new delivery types even exist.

Compile-time and runtime. The difference comes down to when the program decides which specific version of an action to actually run.

Polymorphism generally comes in two broad flavours, and the difference between them comes down to a single question: when does the program decide which specific version of an action to actually run? Understanding this timing difference is genuinely useful, because it explains why the two types feel so different in practice, even though they share the same underlying spirit.

Both types share the same underlying spirit — one consistent way of asking for something, more than one appropriate way of delivering it — but they achieve it through genuinely different mechanics, which the next two sections walk through in detail.

It also helps to notice where each type tends to shine. Compile-time polymorphism is especially handy when the same basic idea needs to accept slightly different inputs — think of a “greet” action that can take just a name, or a name plus a specific time of day for a more personalised greeting. Runtime polymorphism, on the other hand, is especially handy when a program needs to treat a whole family of genuinely different things — different shapes, different animals, different payment types — as interchangeable for the purposes of a single shared action.

Built directly on inheritance and method overriding. The program only figures out which specific version of an action to actually run once it is already executing.

This is the type most people picture first when they hear the word “polymorphism,” and it is built directly on top of inheritance and method overriding, covered in earlier guides in this series. Different classes, related through a shared parent, each provide their own version of the same action. The program only figures out which version to actually run once it is already executing, based on the real, specific object involved.

class Shape:
    def area(self):
        pass

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius
    def area(self):
        return 3.14159 * self.radius ** 2

class Square(Shape):
    def __init__(self, side):
        self.side = side
    def area(self):
        return self.side ** 2

shapes = [Circle(4), Square(5)]
for shape in shapes:
    print(shape.area())

# 50.26544
# 25

The loop at the bottom never checks “is this a Circle or a Square?” It simply calls area() on whatever it is given, and each object correctly computes its own area using its own formula. If a Triangle class were added tomorrow, this exact loop would keep working without a single change, as long as Triangle also provides its own area() method.

This might look like a small convenience in a short example, but picture the same idea applied to a real application with dozens of shape types, each with a genuinely different formula. Without polymorphism, every place in a large program that needs a shape’s area would carry its own long chain of type-checks, and every single one of those chains would need updating whenever a new shape type was introduced. With polymorphism, that entire maintenance burden simply disappears, absorbed quietly into each shape class’s own definition of what “area” means for itself.

This is the exact mechanism that made the Bird, Fish, and Snake example from earlier possible without a long chain of type-checks. Each creature class simply defines its own version of “move,” and the loop calling that action never needs to branch based on type at all. The branching still technically happens somewhere — but it happens automatically, behind the scenes, inside the language itself, rather than being written out explicitly by hand in every place that needs it.

Overloading. One action name, several sensible variations, chosen automatically based on exactly what is handed to it — before the program is running.

This type, often called overloading, lets a single action accept different kinds or numbers of information and still behave sensibly for each situation. Unlike runtime polymorphism, the choice of which specific version to run is worked out early — before the program is actually running — simply by looking at what kind of information was provided.

Another everyday version of this same idea shows up in how people greet each other. Saying “hello” to a close friend, a new acquaintance, or a formal business contact is still fundamentally the same greeting action, even though the specific words and tone shift depending on who is on the receiving end. Compile-time polymorphism captures a similar spirit inside code: one recognisable action name, several sensible variations depending on exactly what is handed to it.

class Calculator:
    def add(self, a, b):
        return a + b

    def add(self, a, b, c):
        return a + b + c

# In languages that support true overloading,
# both versions can coexist, and the correct one
# is chosen automatically based on how many
# values were actually provided.

It is worth being upfront about something: not every programming language supports this in exactly the same way. Some languages, like Java and C++, support true overloading directly, allowing multiple versions of the same action name to coexist as long as they differ in the type or number of inputs they accept. Other languages, like Python, do not support this exact mechanism natively, and developers typically achieve a similar flexible effect using optional or default values instead.

Despite these differences in mechanics, the underlying user experience stays remarkably consistent across languages: someone using a “Calculator” only needs to remember one action name, add, and can trust it to behave sensibly whether they are adding two numbers or three. That consistency — one memorable name, several sensible behaviours — is exactly what makes any form of overloading genuinely useful in day-to-day programming, regardless of which specific language implements it.

If it walks like a duck and quacks like a duck, it is probably a duck. No shared parent required — just the action being asked for.

Some languages take a looser, more relaxed approach to polymorphism, often nicknamed duck typing, based on the old saying: “if it walks like a duck and quacks like a duck, it is probably a duck.” In these languages, an object does not need to formally belong to a particular family through inheritance at all — it just needs to offer the specific action being asked for, and that is considered good enough.

class Duck:
    def quack(self):
        return "Quack!"

class Person:
    def quack(self):
        return "I'm pretending to be a duck!"

for thing in [Duck(), Person()]:
    print(thing.quack())

# Quack!
# I'm pretending to be a duck!

Duck and Person share no formal relationship whatsoever — no shared parent class, no declared interface. Yet the loop happily calls quack() on both, because in a duck-typed language, all that matters is whether an object can actually do the thing being asked of it, not what formal family it officially belongs to.

Languages that lean toward duck typing tend to value flexibility and speed of writing code over strict, upfront guarantees, while languages that require formal inheritance or interfaces tend to value catching mistakes earlier, before the program ever runs, at the cost of a bit more upfront structure. Neither approach is universally “better” — they simply represent two different philosophies about when and how a program should be checked for correctness, and different teams reasonably prefer different trade-offs depending on the kind of software they are building.

Polymorphism is not a magic solution automatically correct in every situation. A fair look means being honest about what it costs as well as what it offers.

Polymorphism, like every idea covered in this series, is not a magic solution that is automatically correct in every situation. It is a genuinely powerful tool, but a fair look at it means being honest about what it costs as well as what it offers.

Most experienced developers consider polymorphism one of the most valuable tools object-oriented programming offers, but they also recognise that its biggest strength — hiding exactly which version of something will run — is also its biggest potential source of confusion if it is used carelessly, without any consistent structure guiding it.

A helpful way to think about this trade-off: polymorphism moves complexity from being visible right in front of you, in the form of a long chain of type-checks, to being distributed quietly across several different classes, each holding its own small piece of the puzzle. This is usually a genuine improvement, since it keeps each individual piece simple and focused. But it does mean that fully understanding what happens when a shared action gets called sometimes requires knowing which classes exist in the family at all, which is a small mental cost worth acknowledging honestly.

A handful of recurring mistakes worth knowing about ahead of time — each easy to recognise once named.

Polymorphism is forgiving in most everyday use, but there are a handful of recurring mistakes worth knowing about ahead of time.

Breaking the promise a shared action makes

If a parent class’s action promises to always return a number, but one child class quietly overrides it to sometimes return nothing at all, any code relying on polymorphism to treat these objects interchangeably can break unexpectedly. Every overridden version should honour the same basic promise the original action made.

Overusing polymorphism where a simple check would do

For a program with only two genuinely fixed, unchanging cases, a full polymorphic design with separate classes can sometimes be more machinery than the problem actually needs. A straightforward conditional check is occasionally the more honest, simpler solution — polymorphism earns its value specifically when the number of related types is expected to grow or change over time.

Relying on duck typing without any safety net

Duck typing’s flexibility is genuinely useful, but without some form of testing or documentation describing what actions an object is expected to support, it becomes easy to accidentally pass in an object that is missing something crucial, only discovering the problem once the program is already running.

Forgetting that overriding still needs a genuine “is-a” relationship

Because polymorphism relies so heavily on inheritance, it inherits — quite literally — the same caution discussed in the earlier guide on inheritance: forcing a class into a shared family purely to gain polymorphic behaviour, without a truly honest “is-a” relationship, tends to produce awkward, hard-to-justify overrides that do not genuinely fit the shared contract everyone else in the family follows.

From media players to printer drivers, polymorphism quietly shapes an enormous amount of the software behind everyday apps and devices.

Polymorphism quietly shapes an enormous amount of the software behind everyday apps and devices. Once the pattern is familiar, it becomes surprisingly easy to spot.

It is also worth noticing polymorphism at work outside of strictly typed programming languages, in places like everyday household technology. A universal remote control is a particularly good example: pressing “Power” sends a single, consistent instruction, but the exact signal produced changes depending on which specific device the remote has been configured to control. The person pressing the button never needs to think about the difference — the same fitting-response pattern this entire guide has been describing, just built into a plastic remote instead of a class hierarchy.

Six honest questions that come up over and over — and honest answers to each.

Is polymorphism the same thing as inheritance?

No, though the two are closely related and often used together. Inheritance is about one class acquiring properties and behaviours from another. Polymorphism is about a single instruction producing different, fitting results depending on which object receives it — which often relies on inheritance having already set up a family of related classes, but the two ideas are genuinely distinct concepts.

Do I need inheritance to use polymorphism at all?

Not necessarily. Formal, inheritance-based polymorphism does rely on a shared family of classes. But duck typing, covered earlier, shows that some languages allow a looser form of polymorphism without any shared inheritance at all — all that matters there is whether an object offers the action being requested.

Which type of polymorphism is more commonly used?

Both are genuinely common, but runtime polymorphism tends to get more attention in discussions about object-oriented design specifically, since it is the mechanism that lets a program work flexibly with families of related, evolving object types — which is a core goal of object-oriented programming itself.

Can polymorphism cause a program to run more slowly?

In most modern languages and typical everyday programs, the difference is small enough that it rarely matters. Determining which specific version of an action to run at runtime does involve a tiny bit of extra work compared to calling a single fixed action directly, but this cost is usually negligible next to the readability and flexibility benefits polymorphism provides.

How is polymorphism different from just having several separate functions with different names?

Separate, differently-named functions require the calling code to already know exactly which one to call, which brings back the very type-checking problem polymorphism is designed to avoid. Polymorphism specifically means one shared, consistent name that automatically produces the correct behaviour, without the caller needing to make that choice itself.

Does every class in a family need to override a shared action?

No. If a child class is perfectly happy with the behaviour it already inherited from its parent, it is entirely free to leave that action untouched. Polymorphism still works correctly in that case — the child simply uses the parent’s version, while any siblings that did choose to override it use their own. Not every member of the family needs to customise every shared action.

A formal name for something everyone already understands instinctively — one consistent instruction, delivered to different things, producing different but appropriate results.

Polymorphism is really just a formal name for something everyone already understands instinctively: one consistent instruction, delivered to different things, producing different but appropriate results — the same way “start” works correctly for a car, a computer, and a race. The next time a single button, a single word, or a single instruction quietly does the right thing no matter what it is pointed at, that is worth noticing — it is the exact same pattern this entire guide has been unpacking, just wearing an everyday disguise.