基类指针的派生类方法:一些替代方法

我猜，你的架构不会满足你的需求——尤其是当你开始扩展它的时候。

我在处理数学表达式方面有一些经验，我想说，最自然的存储表达式的方式是树。每个终端项(如数字或变量)是树的一个叶子，每个非终端项(如操作符或函数调用)是一个节点，它有子节点。例如:

y = x + 5

应该翻译成tree:

  =
 / 
y   +
   / 
  x   5

这种结构的好处是什么?首先，它比令牌向量更容易求值。其次，诸如操作符优先级或关联方向之类的东西仅在构建此结构时才有意义——在构建结构并准备进行评估时不会使用它们。然后，每个节点不关心作为子节点附加到它的内容，它只是让它们评估自己，当完成后，它最终得到一个可以工作的终端项目列表。甚至赋值操作符也可以执行它的工作(当然，如果你传递给它某种包含变量列表的上下文)。

如果你使用著名的反向波兰符号算法，创建这样的结构是非常容易的。

在你的情况下，我投票赞成完全重新排列你的数据结构，这是一个更好的存储表达式。

还有一件事同样根据我的经验，我强烈建议您为这三件事创建不同的类:

• 从输入中读取的项(=令牌)
• 表达式树中包含的项(=一个表达式项)
• 在计算树时作为部分结果的项(= eval对象)

这看起来可能会使您的体系结构复杂化，但实际上会简化您的工作，并使您的体系结构更加灵活。

结构草图

class BaseNode
{
public:
    virtual EvalObject Eval() = 0;
    // This method is handy when working with assignment operator.
    // For instance, Eval() called on variable will return its value
    // but EvalLHS() will return a reference to variable. 
    virtual EvalObject EvalLHS() = 0;
};
class Operator : BaseNode
{
};
class BinaryOperator : Operator
{
private:
    BaseNode * leftChild;
    BaseNode * rightChild;
};
class Add : BinaryOperator
{
public:
    void Eval()
    {
        auto left = leftChild->Eval(); // Eval RHS, 
        auto right = rightChild->Eval(); // Eval RHS
        // Now perform calculations on left and right
        // depending on their types
    }
    void EvalLHS()
    {
        throw InvalidOperationException("Cannot perform LHS evaluation on adding operator");
    }
}
class Assign : BinaryOperator
{
public:
    void Eval()
    {
        auto left = leftChild->EvalLHS();
        auto right = rightChild->Eval();
        // Perform assignment
        // This is required such that operations
        // like a = b = 7 will also work
        return right;
    }
    void EvalLHS()
    {
        // Assignment cannot be on the LHS of operation, eg.
        // (a = 5) = 8 is wrong
        throw InvalidOperationException("Assignment cannot be LHS");
    }
}

我认为设计很差，在这里我将解释原因:
当您进入enum Type时，您实际上承认，尽管您希望拥有一个纯接口，可以在上同样地在任何派生类上工作，但您无法做到。在基类中实现的算法确实需要知道派生类的确切类型才能发挥其作用。在这方面，enum Type和dynamic_cast服务于相同的习语:依赖于确切类型的实现。
这不是面向对象的方式

面向对象的方式声称你的算法，你的代码，用一些基类作为输入的函数，对接口背后的实际对象没有任何假设——只有它的接口重要。
至于你的具体问题，正如上面提到的，我也认为树状结构最适合这个问题。有几种方法可以做到这一点。在我看来，处理它有两个阶段:1。建筑结构;2. 对结构做一些评估。
我将尽量只勾勒(不编译)我的想法，细节和微调留给你:

class Expression
{
};    
class Constant : public Expression
{
    public:
        // 'int' can be easily changed to generic type 'T'
        Constant( int value ) : _value( value ) {}
    private:
        int _value;
};
class Operator : public Expression
{
    public:
        Operator( Expression left, Expression right )
            : _left( left ), _right( right ) {}
    protected:
        Expression _left;
        Expression _right;
};
class OperatorPlus : public Expression
{
    public:
        OperatorPlus( Expression left, Expression right )
            : Operator(_left( left ), _right( right )) {} 
};
// few more operators, the same
class OperatorMinus : public Expression { /* ... */ }
class OperatorMul : public Expression { /* ... */ }
class OperatorDiv : public Expression { /* ... */ }

class Variable : public Expression
{
    public:
        // string can be easily changed to generic type 'T'
        Constant( string value ) : _value( value ) {}
    private:
        string _value; 
}

void f()
{
    // y = x + 5
    OperatorEqual s1( Variable( "y" ), OperatrPlus( Variable( "x" ), Constant( 5 ) ) );
}

class Expression
{
    public:
        virtual Expression eval() = 0;
}

和派生可以很容易地实现它:

class OperatorPlus : public Expression
{
    public:
        OperatorPlus( Expression left, Expression right )
            : Operator(_left( left ), _right( right )) {} 
    virtual Expression eval()
    {
        return _left.eval() + _right.eval();
    }
}

Expression的其他接口可能是print或shorten或combineEqual或任何适合您的域