Re: Some thoughts on polymorphism
On May 2, 5:43 am, chsal...@gmail.com wrote:
I've been programming in C++ for a little over 2 years, and I still
find myself wondering when I should use polymorphism.
Some people claim that polymorphism is such an integral part of C++,
that anybody who doesn't use it might as well just program in plain
C. I totally disagree with this, because I think C++ has a lot of
great features apart from polymorphism, such as the ability to
organize code into classes, code reuse through inheritance, templates,
template specialization, etc.
Polymorphism is only one paradigm. Use it when it's
appropriate; use something else when something else is
appropriate. I find it hard to imagine any largish application
in C++ that didn't make some use of polymorphism, but I am very
sceptical of making everything polymorphic.
Still, most people promote C++ and OO in general because of
polymorphism. But for some reason, I find the idea of defining lots
of little classes that inherit from a base class to be a bit
overreaching just to do something that essentially boils down to a
function pointer.
A function pointer, plus a lot of other things.
Take the following example:
Recently I was working on a project where a server would interpret
various commands issued by a client. There were about 25 different
possible commands. Each command the client issues should cause the
server to respond in a different way.
So what's the best way to implement this in C++?
The first thing that came to mind was a typical C approach: make a
hash table of key words (commands), and associate each key with a
function pointer. This is simple and extremely efficient. But since
I'm programming in C++ I feel compelled to explore more OOish
alternatives. Also, the server program itself was a class, so I'd
need to have the hash table store pointers to functions which are not
part of the class, which kind of breaks the whole design. (Unless I
use dreaded member function pointers - which __nobody__ ever uses, and
which entail considerable overhead to dereference.)
I've used member function pointers on several occasions. It's
one possible solution. If the commands need access to the
context of the calling class, it can be justified.
So, I thought: how about polymorphism? I could create an abstract
base class "command", with a single virtual function, and then make 25
little classes which inherit from it. Then I could just have a
generic execute() function, like:
void execute_command(Command* c)
{
c->dosomething();
}
This seems like it would be the standard C++ way of doing this.
Still, there's something about it that just seems ridiculous. I
define 25 classes, just so I can pick between functions dynamically.
Also, of course, initialize the hash table automatically, and
provide each command with its own environment. Both things that
are bothersome with just function pointers.
On top of that, doing this the old fashioned way (a table of plain
function pointers) is more efficient, since it doesn't involve the
vtable.
Who cares? The difference won't be measurable. (And in
practice, is just as likely to favor derivation.)
For some reason, I don't feel like C++ offers an elegant solution to
this problem.
If you find a table of function pointers, which you have to
manually initialize, and an absense of any context for the
called function elegant...
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34