Geeky OO definition, they let you program to an interface rather than an implementation.
Robert's counter, they make your program slower.
Let's say your programming a game. You make an AbstractPlayer interface for anything that can compete in the game.
Code:
class AbstractPlayer {
public:
virtual Action getInput()=0; // the AbstractPlayer class know how to do this, but subclasses will
void takeDamage();
void getPowerup(PowerUp* p);
protected:
int health;
list<PowerUp*> powerUpList;
};
// AbstractPlayer::takeDamage() and AbstractPlayer::getPowerup() implemented, but NOT AbstractPlayer::getInput(). Note that we cannot actually create AbstractPlayers
This class can provide some functionality, namely handling powerups and taking damage, but it still doesn't actually know how to play the game. There are going to be two different kinds of players, a ComputerPlayer (performs getInput() with artificial intelligence), and a HumanPlayer(performs getInput() by checking the keyboard for input).
Code:
class ComputerPlayer: public AbstractPlayer {
virtual Action getInput();
};
Action ComputerPlayer::getInput() {
// do some wonderful AI crap and return your action
}
class HumanPlayer : public AbstractPlayer {
virtual Action getInput();
};
// implement HumanPlayer::getInput()
Ok, now you have your interface (AbstractPlayer), and two subclasses, HumanPlayer, and ComputerPlayer. Now you actually want to make something that drives the game.
Code:
class GameRunner {
public:
void runGame();
void addCompPlayer();
void addHumanPlayer();
private:
list<AbstractPlayer*> playerList;
};
void GameRunner::addCompPlayer() {
playerList.push_back(new ComputerPlayer);
}
void GameRunner::addHumanPlayer() {
playerList.push_back(new HumanPlayer);
}
void GameRunner::runGame() {
// do stuff
for (list<AbstractPlayer*>::iterator i = playerList.begin(); i != playerList.end(); i++) {Action a = (*i)->getInput();
switch (a) {
case FIRED_WEAPON:
// handle it
break;
case MOVE_RIGHT:
// handle it
break;
// more cases
};
}
}
notice how we don't care what type of player the currentPlayer is.. we just care that we can get input from it. It would be possible to not change this function at all, and add network play (theoritically, at least, in practice, your gonna have to do some other stuff like syncronization) by adding a NetworkPlayer subclass of AbstractPlayer and an addNetworkPlayer option to the GameRunner (trivial), but the runGame function can stay the same.
In the practical sense, they are like function pointers in C, as they decide which function is called at runtime. Evertying you can do with virtual funcs in C++, you could do with function pointers in C, but its a hell of a lot prettier in C++.
[ This Message was edited by: SilentStrike on 2002-03-09 22:58 ]