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

Разделите оператор на два разных метода, например, 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();
   };

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

Подробное обсуждение того, почему NVI желательны, можно найти в "Стандартах кодирования C++" Херба Саттера. Там он доходит до того, что предлагает сделать все публичные функции невиртуальными, чтобы добиться строгого отделения переопределяемого кода от кода публичного интерфейса (который не должен быть переопределяемым, чтобы вы всегда могли иметь централизованный контроль и добавить инструментарий, проверку предварительных и последующих условий и все остальное, что вам нужно).

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 не знал, какие аргументы нужны каждой функции, и поэтому было легко управлять различными функциями.

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

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

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