Автоматический вызов метода базового класса C++

Похоже, вы можете извлечь выгоду из идиомы NVI (невиртуальный интерфейс). Там интерфейс объекта command не будет иметь виртуальных методов, но вызовет приватные точки расширения:

class command {
public:
   void operator()() {
      do_command();
      add_to_undo_stack(this);
   }
   void undo();
private:
   virtual void do_command();
   virtual void do_undo();
};

У этого подхода есть различные преимущества, первое из которых заключается в том, что вы можете добавить общие функции в базовый класс. Другие преимущества заключаются в том, что интерфейс вашего класса и интерфейс точек расширения не связаны друг с другом, поэтому вы можете предлагать разные подписи в своем общедоступном интерфейсе и в виртуальном интерфейсе расширения. Ищите NVI, и вы получите гораздо больше и лучшие объяснения.

Приложение: Оригинальная статья Херба Саттера, в которой он представляет концепцию (пока без названия)

Разделите оператор на два разных метода, например. execute и executeImpl (если честно, мне не очень нравится оператор ()). Сделайте Command::execute не виртуальным, а Command::executeImpl чистым виртуальным, затем позвольте Command::execute выполнить регистрацию, затем вызовите его executeImpl, например:

class Command
   {
   public:
      ResultType execute()
         {
         ... // do registration
         return executeImpl();
         }
   protected:
      virtual ResultType executeImpl() = 0;
   };

class SomeCommand
   {
   protected:
      virtual ResultType executeImpl();
   };

Предполагая, что это «обычное» приложение с отменой и повтором, я бы не стал пытаться смешивать управление стеком с действиями, выполняемыми элементами в стеке. Это будет очень сложно, если у вас либо несколько цепочек отмены (например, открыто более одной вкладки), либо когда вы делаете-отменить-повторить, когда команда должна знать, добавить ли себя в отмену или переместиться из повтора в отмену, или перейти от отмены к повтору. Это также означает, что вам нужно имитировать стек отмены/возврата, чтобы протестировать команды.

Если вы хотите смешать их, у вас будет три шаблонных метода, каждый из которых берет два стека (или объект команды должен иметь ссылки на стек, с которым он работает при создании), и каждый выполняет перемещение или добавление, а затем вызывает функция. Но если у вас есть эти три метода, вы увидите, что они на самом деле не делают ничего, кроме вызова общедоступных функций в команде, и не используются какой-либо другой частью команды, поэтому станьте кандидатами в следующий раз, когда вы рефакторите свой код. для сплоченности.

Вместо этого я бы создал класс UndoRedoStack с функцией execute_command(Command*command) и оставил бы команду максимально простой.

По сути, предложение Патрика совпадает с предложением Дэвида, которое также совпадает с моим. Используйте для этой цели NVI (идиома невиртуального интерфейса). Чисто виртуальные интерфейсы лишены какого-либо централизованного управления. В качестве альтернативы вы можете создать отдельный абстрактный базовый класс, который наследуют все команды, но зачем?

Подробное обсуждение того, почему NVI желательны, см. в статье Herb Sutter Standards Coding Standards. Там он заходит так далеко, что предлагает сделать все публичные функции невиртуальными, чтобы добиться строгого отделения переопределяемого кода от общедоступного кода интерфейса (который не должен быть переопределяемым, чтобы вы всегда могли иметь некоторый централизованный контроль и добавлять инструментарий, до/после). проверка состояния и все, что вам нужно).

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;
};

Если мы сделаем шаг назад и посмотрим на общую проблему, а не на непосредственный вопрос, я думаю, что Пит предлагает очень хороший совет. Возложение на Command ответственности за добавление себя в стек отмены не является особенно гибким. Он может быть независимым от контейнера, в котором находится. Эти обязанности более высокого уровня, вероятно, должны быть частью фактического контейнера, на который вы также можете возложить ответственность за выполнение и отмену команды.

Тем не менее, изучение NVI должно быть очень полезным. Я видел слишком много разработчиков, которые пишут чистые виртуальные интерфейсы, подобные этому, из исторических преимуществ, которые у них были только для того, чтобы добавить один и тот же код к каждому подклассу, который его определяет, когда его нужно было реализовать только в одном центральном месте. Это очень удобный инструмент, который можно добавить в свой набор инструментов для программирования.

Однажды у меня был проект по созданию приложения для 3D-моделирования, и для этого у меня было такое же требование. Насколько я понял при работе над ним было то, что несмотря ни на что и операция всегда должна знать, что она сделала и, следовательно, должна знать, как это отменить. Итак, у меня был базовый класс, созданный для каждой операции, и его рабочее состояние, как показано ниже.

class OperationState
{
protected:
    Operation& mParent;
    OperationState(Operation& parent);
public:
    virtual ~OperationState();
    Operation& getParent();
};

class Operation
{
private:
    const std::string mName;
public:
    Operation(const std::string& name);
    virtual ~Operation();

    const std::string& getName() const{return mName;}

    virtual OperationState* operator ()() = 0;

    virtual bool undo(OperationState* state) = 0;
    virtual bool redo(OperationState* state) = 0;
};

Создание функции и ее состояния будет выглядеть так:

class MoveState : public OperationState
{
public:
    struct ObjectPos
    {
        Object* object;
        Vector3 prevPosition;
    };
    MoveState(MoveOperation& parent):OperationState(parent){}
    typedef std::list<ObjectPos> PrevPositions;
    PrevPositions prevPositions;
};

class MoveOperation : public Operation
{
public:
    MoveOperation():Operation("Move"){}
    ~MoveOperation();

    // Implement the function and return the previous
    // previous states of the objects this function
    // changed.
    virtual OperationState* operator ()();

    // Implement the undo function
    virtual bool undo(OperationState* state);
    // Implement the redo function
    virtual bool redo(OperationState* state);
};

Раньше был класс под названием OperationManager. Это зарегистрировало различные функции и создало их экземпляры внутри него, например:

OperationManager& opMgr = OperationManager::GetInstance();
opMgr.register<MoveOperation>();

Функция регистрации была такой:

template <typename T>
void OperationManager::register()
{
    T* op = new T();
    const std::string& op_name = op->getName();
    if(mOperations.count(op_name))
    {
        delete op;
    }else{
        mOperations[op_name] = op;
    }
}

Всякий раз, когда функция должна была быть выполнена, она будет основываться на выбранных в данный момент объектах или на том, над чем ей нужно работать. ПРИМЕЧАНИЕ. В моем случае мне не нужно было отправлять сведения о том, насколько должен двигаться каждый объект, потому что это вычислялось MoveOperation с устройства ввода после того, как оно было установлено в качестве активной функции.
В OperationManager выполнение функции будет выглядеть так:

void OperationManager::execute(const std::string& operation_name)
{
    if(mOperations.count(operation_name))
    {
        Operation& op = *mOperations[operation_name];
        OperationState* opState = op();
        if(opState)
        {
            mUndoStack.push(opState);
        }
    }
}

Когда есть необходимость отменить, вы делаете это из OperationManager следующим образом:
OperationManager::GetInstance().undo();
И функция отмены OperationManager выглядит следующим образом:

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.
        }
    }
}

Из-за этого OperationManager не знал, какие аргументы нужны каждой функции, и поэтому управлять разными функциями было легко.