Appelez automatiquement une méthode de classe de base C ++

En supposant que c'est une application «normale» avec annulation et refaire, je n'essaierais pas de mélanger la gestion de la pile avec les actions effectuées par les éléments sur la pile. Il sera très compliqué si vous avez de multiples chaînes d'annulation (plus d'une seule onglet ouverte) ou lorsque vous le faites-endo-redo, où la commande doit savoir s'il faut s'ajouter à annuler ou à se déplacer de Refaire pour annuler, ou se déplacer d'annuler pour refaire. Cela signifie également que vous devez vous moquer de la pile annulation / redo pour tester les commandes.

Si vous voulez les mélanger, vous disposerez de trois méthodes de modèle, chacune de la prise des deux piles (ou que l'objet de commande doit avoir des références aux piles qu'il fonctionne lors de la création de personnes créées), et chacun effectuant le déplacement ou l'ajout. , puis appelant la fonction. Mais si vous avez ces trois méthodes, vous verrez qu'ils ne font rien d'autre que d'appeler des fonctions publiques sur la commande et ne sont utilisées par aucune autre partie de la commande, devenez donc candidats la prochaine fois que vous refactez votre code. pour la cohésion.

Au lieu de cela, je créerais une classe UNDOREDOSTACCACCACTACT qui a une fonction Execute_Command (Command * Commande) et laissez la commande aussi simple que possible.

La suggestion de Patrick est la même que celle de David qui est aussi la même chose que la mienne. Utilisez NVI (Idiome d'interface non virtuelle) à cette fin. Les interfaces virtuelles pures manquent de tout type de contrôle centralisé. Vous pouvez également créer une classe de base abstraite distincte que toutes les commandes hériter, mais pourquoi se déranger?

Pour une discussion détaillée sur la raison pour laquelle NVIS est souhaitable, voir C ++ Codage normes de Sutter. Là-bas, il va jusqu'à suggérer de faire de toutes les fonctions publiques non virtuelles pour obtenir une séparation stricte du code excédentaire du code d'interface publique (qui ne devrait pas être répréhensible afin que vous puissiez toujours avoir un contrôle centralisé et ajouter une instrumentation, pré / post- Vérification des conditions, et tout ce dont vous avez besoin). P>

class Command 
{
public:
   void operator()() 
   {
      do_command();
      add_to_undo_stack(this);
   }

   void undo()
   {
      // This might seem pointless now to just call do_undo but 
      // it could become beneficial later if you want to do some
      // error-checking, for instance, without having to do it
      // in every single command subclass's undo implementation.
      do_undo();
   }

private:
   virtual void do_command() = 0;
   virtual void do_undo() = 0;
};

J'ai déjà eu un projet de création d'une application de modélisation 3D et que j'avais l'habitude d'avoir la même exigence. Autant que je sache, lorsque vous travaillez, c'était que peu importe ce que l'opération devrait toujours savoir ce qu'elle a fait et devrait donc savoir comment l'annuler. J'ai donc eu une classe de base créée pour chaque opération et son état de fonctionnement comme indiqué ci-dessous.

void OperationManager::undo()
{
    if(!mUndoStack.empty())
    {
        OperationState* state = mUndoStack.pop();
        if(state->getParent().undo(state))
        {
            mRedoStack.push(state);
        }else{
            // Throw an exception or warn the user.
        }
    }
}