1
votes

I am learning OOP concepts, which do not really have well-established definitions.

I heard different things about polymorphism and can not decide what is right.

Most people will say that it is a type-theory. Meaning that a function is able to accept multiple types of parameters that have something in common.

Ad hoc polymorphism is about different overloads of the same function.

Parametric polymorphism is generic functions.

Subtyping polymorphism is that if a function accepts a certain class as parameter, it can also accept its subclasses. (Of course only those can be passed as parameter which are not abstract but concrete).

There is a seemingly different definition. There are those who say polymorphism means that a function can have different implementations (morphs/forms). In that sense... - interface functions, - abstract classes’ abstract functions, - and virtual functions that can be overridden by the subtype ...are all considered polymorphic.

As I was told, polymorphism in this sense can be defined as having different results if the same function is called on different objects.

And adding to the confusion, someone said only virtual functions are polymorphic because they already have an implementation.

For me the first way I presented polymorphism and the second seem completely different, but maybe they both fit the definition of polymorphism and it is just me being unable to understand it.

So what is polymorphism in programming? Is it just a type-theory?

In this question I would like to refer to this question: https://stackguides.com/questions/25163683/polymorphism-and-interfaces-clarification#=

It raises almost the same problem, but I could not really make out the conclusion.

1
To simplify the problem - I find that the easiest to way to define and understand Polymorphism is this: the ability to look at one thing from many different angles. - Zohar Peled

1 Answers

1
votes

Yes and No.

Yes, in classic inherited languages it works that way.

No, since in other languages the calling of a method on an object might be dynamically resolved. (e.g. by runtime code searching in a list of objects as a field, so called aggregate in COM terms)

IOW that that method exists in the type of the object is not defined in type theory. At least not universal. The language might not even be typed.

For a statically inherited object model, it is however true. IOW Typing (subtyping/inheritance, de concept of virtual methods) is an implementation of polymorphism in languages with such object model. But not all languages do.

Some have dispatch polymorphism, and can add methods runtime (like objective C) or figure out of the method exists at all (e.g. COM IDispatch )

The classic test of polymorphism is the "the duck quacks". Where you have a generic "animal" and call a method for "makesound", and if you assigned a duck it "quacks". So you call a method (pass a message in old OO jargon) on an generic object, and you get the behaviour of the more specialized object assigned to it.

What constitutes a "generic" object depends on the language. In statically inherited languages the generic object must have the method declared, sometimes with special modifiers (virtual) to signal overridability.

In other languages the generic object can be the root object, and the runtime will figure out if it has a makesound method.