C++ de la Création de la Classe Enfant d'une Classe Parent qui a déjà été initialisé

L'idée avec le polymorphisme, c'est que si vous avez un peu de classe:

class Batter : public Player

Puis tous pâte est aussi un joueur. Ainsi, par exemple, si vous avez eu une pâte appelée dave, vous seriez en mesure d'utiliser dave où un Joueur a été prévu. Vous pourriez par exemple:

int FunctionThatDoesSomething(Player &p, string some_parameter, ...);

...

FunctionThatDoesSomething(dave, "foo", ...);

Être prudent pour éviter de découpage, qui est accidentellement lorsque vous faites une classe de base copie d'une sous-classe (ce qui ne permet pas de conserver la sous-classe spécifique de l'état. Si vous avez besoin de passer dave autour, assurez-vous de ne reportez-vous à dave, de ne pas copier dave. dave n'aime pas être copié.)

Exactement comment vous construisez vos joueurs et de pâtes est à vous. Par exemple, il peut être de constructeurs avec ces signatures:

Player::Player(string name, string role, int vFFDefense);
Batter::Batter(Player &p, int vTouch, int moreStats);

Dans certaines circonstances, cela peut être pratique, mais elle n'est pas particulièrement efficace, parce que vous devez créer et de copie de la classe de base (pas que l'efficience est une grosse affaire pour les petites classes comme ça, mais il n'y a aucun point dans essayer faire les choses de la muette chemin). Vous serait mieux de faire un constructeur qui prend tout ce dont il a besoin, et utilise des sous-objet d'initialisation:

Batter::Batter(string name, string role, int vFFDefense, int moreBaseStats, int vTouch, int moreStats) : Player(name, role, vFFDefense, moreBaseStats)
{
    ...

Mais votre mise en œuvre est finalement à vous.

Ça dépend vraiment de la façon dont vous voulez vraiment votre code de le prendre en compte.
Une donnée Player jamais devenir autre chose qu'un Batter? Si on le peut, alors il est probablement préférable d'utiliser l'agrégation (de manière similaire à la façon dont vous le faites aujourd'hui).

Si vous êtes l'agrégation, alors peut-être utiliser une autre classe afin de conserver les données. Vous pourriez avoir un PlayerInfo classe ou structure et d'agrégats:

struct PlayerInfo
{
    string role_;
    int ff_defence_;
    ...
};

class Player 
{
public:
    Player(PlayerInfo const& info)
        : info_(info)
    {}
    virtual ~Player() = 0;
    virtual void doSomething();

    PlayerInfo const& getPlayerInfo() const { return info_; }
private:
    PlayerInfo info_;
};

class Batter : public Player
{
public:
    Batter(PlayerInfo const& info)
        : Player(info)
    {}
    virtual void doSomething();
};

Si vous voulez réellement l'héritage, puis d'autres réponses ici vous dire ce que vous devez faire - construire une instance de Batter et de passer sur les arguments du constructeur à un constructeur de la classe, vous en dérivent (par exemple Batter) pour l'initialiser.

Réfléchissez bien à ce que vous essayez d'exprimer dans votre code.

La raison pour laquelle vous voulez avoir Batter dérivé de Player est si vous avez besoin de fonctions virtuelles dans Player qui sont mis en œuvre dans Batter et faire quelque chose de différent, selon qu'il est ou non un Player ou un Batter.

En aparté, de son mieux pour garder les classes de base abstraites, si possible, de sorte Player ne serait jamais instanciée directement et aurait toujours besoin d'être dérivée. Je vous recommande la lecture de Scott Meyers Plus Effective C++ " pour comprendre pourquoi il en est. Il y a une section consacrée à cela. En fait, certains des points les plus fins de l'héritage et OO le design en général sont très bien expliqué.

Ce que vous voulez vraiment est quelque chose de légèrement différent selon l'endroit où vous prévoyez que votre modèle de changement, et en outre où avez-vous besoin d'avoir le comportement dynamique possible grâce à l'utilisation de fonctions virtuelles?

Vous pourriez avoir un Player classe qui a tous de votre joueur des détails spécifiques. Alors vous pourriez avoir un PlayerBehaviour classe qui implémente ce que le joueur n':

class Player;

class PlayerBehaviour
{
public:
    virtual ~PlayerBehaviour() = 0;
    virtual void doSomething(Player* player) = 0;
};
inline PlayerBehaviour::~PlayerBehaviour() {}

class BatterBehaviour : public PlayerBehaviour
{
public:
    virtual void doSomething(Player* player) {
        if (player->isAngry()) {
            throwBatOnFloor();
        }
    }
    void throwBatOnFloor();
};

class Player {
public:
    Player(...stuff...);

    void doSomething() {
        if (behaviour_.get()) {
            behaviour_->doSomething(this);
        }
    }
private:
    auto_ptr<PlayerBehaviour> behaviour_;
    //Due to the auto_ptr, the default copy and assignment operators are
    //dangerous.  You could use a smart pointer or implement 
    //these by having a clone() function in the behaviour class.
    //Therefore copy/assign are private to prevent accidental misuse.
    Player(Player const&);
    Player& operator=(Player const&);
}; 

Donc, héritant Batter de Player modèles de la situation comme un Batter est-un Player.
Avoir un Behaviour modèles de la situation comme un Player a-un Behaviour comme un Batter.