The topic of polymorphism is given mystical status in some programming texts and is ignored in others, but it’s a simple, useful concept that the C++ language supports. Find out all about it in this sample chapter by Stephen Dewhurst.
C++ Common Knowledge: Polymorphism
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Polymorphism is a staple.
Polymorphism is a staple
… for example?
Polymorphism, inheritance, abstraction, and encapsulation are the four key concepts of OOP. Polymorphism being arguably the most powerful (and most confusing in my opinion.)
… for example?
are you serious?
My perl scripts do this.
Polymorphism.. what an unnecessarily long word, like unnecessarily.
Isn’t polymorphism just interitance from multiple objects?
And data abstraction and encapsulation is just hiding your data behind functions designed to manage it.
OOP can be done in almost any language. Its all about keeping code and data separate, IMO.
Isn’t polymorphism just interitance from multiple objects?
No. Polymorphism is what allows you to use the same identifier for different functions, as defined in any number of classes, because the compiler is able to resolve which version of a function is being called based on an object’s class.
OOP can be done in almost any language. Its all about keeping code and data separate, IMO.
Sure, you can achieve a level of data abstraction and encapsulation with a purely procedural language like C, but languages which are designed to be object-orientented are much more elegant in their ability to implement them.
Isn’t polymorphism just interitance from multiple objects?
No it’s not. That’s what this article alludes to but the article is on the wrong track. Polymorphism is the ability of an object/function/container to act with common functionality to different data types. In the article he is talking about polymorphic base classes, which is where the confusion is.
If instead he had talked about a class such as a List class, that had a sort method. Then you could say that the list class could take a list of numbers(ints/floats) or a list of words(strings). Then the sort method would work depending on the type of the list (sorting ints, floats and strings all using different code). This sort method would then be polymorphic. The fact that the list class could hold different datatypes makes the class polymorphic.
There is a better but not the best description in wikipedia.
http://en.wikipedia.org/wiki/Polymorphism_%28computer_science~*…
I would not buy that book, considering how badly that section was written.
(warning, indentations and include iostream have been strippd due to restriction in this commenting form!)
#include <iostream>
class Person{
public:
virtual std::string Talk() const { return “Hello world.”; }
virtual ~Person(){}
};
class Physicist:public Person{
public:
virtual std::string Talk() const { return “e=mc^2”; }
};
class Salesman:public Person{
public:
virtual std::string Talk() const { return “sell!”; }
};
void Podium( const Person& p ){
std::cout << p.Talk() << std::endl;
}
int main(){
Person p;
Physicist einstien;
Salesman trump;
// here’s where the polymorphism takes place.
// We’re using inherited people who give different speeches.
Podium(p);
Podium(einstien);
Podium(trump);
return 0;
}
Polymorphism is the ability to decide, at runtime, which derived class a base class should be initialised to, as is aptly illustrated by the code shown in the post above. One uses the virtual keyword to achieve this effect.
However, this article is way too confusing. Firstly, the
article uses financial options, with which many programmers are not familiar and frankly, more simple illustrative metaphors are available. Then, the explanations are just not lucid or intuitive.
Thanks for reminding me, its been a while since I really bought into OOP and the dozen or so idioms that come with it.
The article turned me off in 2 paragraphs, your example was as clear as it gets.
Still I find myself working mostly in plain C and HW languages though, never really seing much use for most of the OO other than basic object management. I guess if one is writing the kind SW that was also well written for 2 decades before OOP became pervasive then I can take a pass.
I wish though that in CS circles, OO would be tought in a way that you know what the code will do and look like after the compiler has reduced the OO constructs. While an example can show what you might write without a feature v with the feature, I am more interested to know how the compiler reduces these things and where things gets screwed up esp if you play all the idioms together.
my 2cents
Mostly because of the word itself… “polymorphism.” Go ahead.. say it out loud. It’s fun! 🙂
This isn’t the first time this book has been mentioned here on OSNews. Check out this previous thread (there may be others):
http://www.osnews.com/comment.php?news_id=10252
Based on what I’ve seen in these two sample chapters, I would not recommend buying it. While I don’t claim to be a C++ expert, what I’m seeing here is some very confusing and misleading descriptions of some fundamental concepts of OO and C++. It looks like it wants to be an informal introductory text, but it reads like an article written by a journalist who had everything described to him over the phone.
Polymorphism is a shopping trolley.
This thread/page asks a similar question about how to turn C++ into assembly.
http://answers.google.com/answers/threadview?id=488746
“Inside the C++ Object Model” by Stanley B.
Lippman (Addison-Wesley Professional, 1996).
Review here
http://www.ercb.com/feature/feature.0037.html
Also I found this page on turning Simula 67 into C
http://www.cs.uiowa.edu/~jones/assem/summer97/notes/23.html
I found this course which involves using high level macros in assembly to create OO software
http://www.bixoft.nl/english/course6.htm
Thanks for that, I know Lippman’s books, I’m sure I have one but I hadn’t seen this one, shame on me. Will explore it at the local store. The reference looks glowing except for the last part, 1996 dated & missing the new stuff on exceptions etc. Better check Amazon too.
What I’d really like is Hanson & Fraser LCC brought upto date with objects in the original style of H & F, the most practical compiler book I have, but I doubt that could happen now.
C++ is on the wrong track with subclassing. Subclassing throws subtyping (one case of polymorphism) and inheritance together although they’re actually different things.
This isn’t the first time this book has been mentioned here on OSNews. Check out this previous thread (there may be others):
http://www.osnews.com/comment.php?news_id=10252
Based on what I’ve seen in these two sample chapters, I would not recommend buying it. While I don’t claim to be a C++ expert, what I’m seeing here is some very confusing and misleading descriptions of some fundamental concepts of OO and C++.
Based on these excerpts, I would agree. However I know that the book is derived from a number of articles the author had on his webpage for some time. Most of them were good. So for the audience the book is targeted (“intermediate” users), I do not want to discourage reading it.
I am a bit stunned that Informit publishes the weaker parts.
“C++ is on the wrong track with subclassing. Subclassing throws subtyping (one case of polymorphism) and inheritance together although they’re actually different things. ”
Can you explain what you mean here?
To abuse the classic Animal metaphor — You want to install a cat door so your cat can come and go, and your engineer friend proposes to design a door that will admit all ____. Fill in the blank – all cats (house cats, bobcats, mountain lions …), or all house pets (cats, dogs, miniature pigs, …)?
“Cat” is an implementation class , where modest DNA differences in the subclasses produce things that are similar but don’t belong together. House pet is a type (subtype of domesticated animal) of things that can be implemented however however you like but have certain important properties in common.
OOP is not the only way polymorphism can happen, or even a particularly outstanding way.
Folks, I am somewhat perplexed as to why folks here need a paper on polymorphism. This is an essential fundmental even for beginner to OOP. Granted, it can be a difficult concept to grasp initially, but its kinda like riding a bicycle after that.
I’m missing something here.
In technical terms: If A is a subtype of B, then a reference of type A can be upcast to type B without a runtime check. It means that class A fulfils the contract declared by class B, e.g. offers (among others) compatible (if not the same) method signatures that B offers.
Inheritance means to re-use code without copy&paste and without refactoring, by just placing a link in a class definition referring to code from another class.
Very often one wants either subtyping or inheritance, but not both. Then the coupling gets in the way, but the problem is usually ignored, leading to “bad OOP code”.
Furthermore, current OOP languages allow sublcassing from any class if not explicitly forbidden. For subtyping this is not a problem – actually there is little reason to forbid subtyping except if there is only one sensible implementation of the class’s contract, or to increase performance. But for inheritance, it breaks encapsulation completely.
Polymorphism makes it possible to mix apples an oranges (they are all fruits).
Yes, but eating an apple often doesn’t involve peeling it.
Sometimes those concepts in polymorphism of making everything conform to the same api isn’t as important as what’s really happening between these objects and how they share methods and data, IMO.
Most of the books i read, have just outlined what is polymorphism and some examples snippets.
However, where exactly to apply polymorphism is not explained or very few details are given.