Polymorphism

Artist's impression of a polymorph.

Polymorphism is something that most programmers have heard of yet vaguely understand, much like women, dating women or showering (with or without women). This is because polymorphism was never meant to be understood. Polymorphism is just one of the many baffling properties of object oriented programming.

Put simply in layman terms, polymorphism means there is a class that masquerades as another class while telling everyone that it is, in fact, the class as it was originally created even though it has quite plainly and obviously to everyone concerned, inherited its features from that other class which may or may not be its own subclass, depending on the dubious breeding of the programmer who wrote it.

History

In the early days of programming languages a thing was a thing. Everyone knew what a thing was and programmers were happy. The only person who wasn't happy was an AI entity known as the Stroustrup who existed in a far away land called Daneland (for he was Danish). He was an evil being who decided that programmers should not know what things are. Only the machines that cranked through the programmers' code may have the right to know what a thing is. He reasoned that the mortal minds of programmers could not cope with the sacred knowledge of thing-ness.

The Stroustrup proclaimed that programmers must begin to think of things as non-things, or non-things that might be other things. A non-thing could potentially be many things and morph into any one of them unexpectedly at any time. The Stroustrup pondered this and decided to name a non-thing a polymorph. Having decided this, he unleased his army of polymorphs from his tower and ordered them to fly away and infect the minds of programmers everywhere. Thus programmers all over the land and indeed the world became less happy.

Usage

The successful use of polymorphism in everyday life is dependent on following a few basic rules and principles. These can be summarised as follows:

Rules of polymorphism

This might be a dog but best not to assume.

1. Never refer to a thing by what it actually is. For example, don't tell someone that you have two cats, a dog and three ducks. All you need to say is you have six animals. If pressed for more information, simply tell them that they each have two eyes and eat through an opening in their face - that is, they have a common interface, which is all that is required to keep people guessing.
2. A thing will magically know what to do even if you don't know what it is. To demonstrate this, blindfold yourself and stand in front of your six animals which have been arranged in a random order by someone who may or may not be known to you. Also, if you don't know the other person, it probably isn't a good idea to be blindfolded in their presence. Now point to the first animal (which you can't see and therefore don't know what it is) and tell it to make a sound. Shout at it if necessary. If it barks, you know it is more than likely a dog. However if you remember rule 1, this doesn't then give you the right to start referring to this animal as a dog. It is still merely an animal that exhibits dog-like behaviour.
3. When a thing dies you can still ignore what it actually is. Following the preceding two examples, all you should write on its headstone is 'here lies an animal' and you know that you now have one less animal to deal with. The odds are relatively high that it is a duck but it is dangerous to make assumptions. Doing something to a cat when you think it's a duck can have disastrous consequences.

Best practices

One possible consequence of incorrectly assuming a thing showing duck-like behaviour is a duck.

• Consistent interfaces. All things are designed to evolve over time, as Charles Darwin once proved. This evolution should not be noticeable by anyone if they can keep using things as if nothing had changed without giving any thought to what is going on inside them. Consistent interfaces are key to this. So when it comes time to upgrade that duck, don't introduce any new ways that a person already familiar with ducks could interact with it. An extra bill on its face that has no function other than to quote Shakespeare might cause unnecessary confusion.
• Use overloads judiciously. There are some animals in existence that exhibit more than one method of ambulation. For example a duck may waddle on its legs or use its legs to propel itself across water. Of course ducks can also use their wings to fly, but for the tenuous purposes of this example we are only looking at the overloaded functions of its legs. Two or three overloaded functions is probably optimal; any more and the duck would become exponentially more complex to design and use. Everyone expects that a duck responding to the function walk will cause the duck to waddle along the ground towards the nearest human offering bread. Other uses for walking are undefined.
• A duck is probably a duck. However it could also be a turtle pretending to be a duck. Assuming a duck is a duck based on its behaviour is a different form of polymorphism and should be avoided. Always interact with a duck abstractly through its base animal interface and the duck itself will take care of the details.

This is your future.

The future of polymorphism

As programmers become lazier and programming languages continue to fill in the details that programmers can't be bothered thinking about, polymorphism will eventually reach its logical conclusion and all things will inherit the Ultimate Interface. This is where everything that can be conceivably thought of has already been thought of by other programmers and all possible functionality is built into the Ultimate Interface. Everything built off the Ultimate Interface may need no additional work to behave correctly; some may need to override certain functions for custom behaviour but these instances will be few and far between and machines will soon learn to act one way or another based on heuristic analysis. One day programmers may become an extinct species thanks to continued advances in polymorphism.