In object-oriented programming theory, polymorphism is the ability of objects belonging to different types to respond to methods of the same name, each one according to the right type-specific behavior. The programmer (and the program) does not have to know the exact type of the object in advance, so this behavior can be implemented at run time (this is called late binding or dynamic binding).

The different objects involved only need to present a compatible interface to the clients (the calling routines). That is, there must be public methods with the same name and the same parameter sets in all the objects. In principle, the object types may be unrelated, but since they share a common interface, they are often implemented as subclasses of the same parent. Though it is not required, it is understood that the different methods will also produce similar results (for example, returning values of the same type).

Advantages of polymorphism

Polymorphism allows client programs to be written based only on the abstract interfaces of the objects which will be manipulated (interface inheritance ). This means that future extension in the form of new types of objects is easy, if the new objects conform to the original interface. In particular, with object-oriented polymorphism, the original client program does not even need to be recompiled (only relinked) in order to make use of new types exhibiting new (but interface-conformant) behavior. (In C++, for instance, this is possible because the interface definition for a class defines a memory layout, the virtual function table describing where pointers to functions can be found. Future, new classes can work with old, precompiled code because the new classes must conform to the abstract class interface, meaning that the layout of the new class's virtual function table is the same as before; the old, precompiled code can still look at the same memory offsets relative to the start of the object's memory in order to find a pointer to the new function. It is only that the new virtual function table points to a new implementation of the functions in the table, thus allowing new, interface-compliant behavior with old, precompiled code.)

Since program evolution very often appears in the form of adding new types of objects (i.e. new classes), this ability to cope with and localize change that polymorphism allows is the key new contribution of object technology to software design.

Examples

Python makes extensive use of polymorphism in its basic types. For example, strings (immutable sequences of characters) and lists (mutable sequences of elements of any type) have the same indexing interface and the same lookup interface (which call the appropriate underlying methods).

   myString = 'Hello world'
   myList = [0, 'one', 1, 'two', 3, 'five', 8]

   print myString[:4]  # prints Hell
   print myList[:4]    # prints [0, 'one', 1, 'two']

   print 'e' in myString   # prints True
   print 5 in myList       # prints False

However, the most common examples of polymorphism are found in custom classes. Consider the very silly example below, where two subclasses (Cat and Dog) are derived from an Animal superclass. Two Cat objects and one Dog are instantiated and given names, and then they are gathered in a list ([a, b, c]) and their talk method is called.

   class Animal:
       def __init__(self, name):
           self.name = name

   class Cat(Animal):
       def talk(self):
           return 'Meow!'

   class Dog(Animal):
       def talk(self):
           return 'Arf! Arf!'

   a = Cat('Missy')
   b = Cat('Mr. Bojangles')
   c = Dog('Lassie')

   for animal in [a, b, c]:
       print animal.name + ': ' + animal.talk()

   # prints the following:
   #
   # Missy: Meow!
   # Mr. Bojangles: Meow!
   # Lassie: Arf! Arf!

Note that Python makes polymorphism particularly practical, since it is not strongly typed: a variable can hold objects of any type or class, and the elements of a list can be of mixed classes too (unlike a C array).

Other concepts

There are several other concepts called polymorphism in computer science theory. The Liskov substitution principle is closely related and is generally accepted as the definition for sub-type polymorphism.

Finding out the type of an object through code, and then calling an appropriate method, is not polymorphism, and in fact it is usually a bad practice in OOP. While in structured programming type-testing may be the only way to deal with some situations, OOP is designed to avoid it.