Может, я неправильно распорядился наследством?

Таким образом, у вас есть дерево, узлы которого имеют два различных типа, производных от одного и того же основания, и вы хотите выполнить операцию над одним типом, но не над другим ... это похоже на работу для шаблона посетителя. :)

Идея паттерна visitor^ заключается в следующем: он обеспечивает возможность для элементов сложных структур (деревьев, графов) работать по-разному в зависимости от их типа (который известен только во время выполнения), и где сама конкретная операция также может быть известна только во время выполнения. runtime, без необходимости изменять всю иерархию, к которой принадлежат элементы (т. е. избегать таких вещей, как реализация функции "ошибка" addToBalance, о которой вы подумали). (^Он имеет мало общего с посещением, поэтому, вероятно, неправильно назван - это скорее способ достижения двойной отправки для языков, которые изначально его не поддерживают.)

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

class Visitor {

  virtual void Visit(ParentAccount*) { /* do nothing by default*/ }
  virtual void Visit(ChildAccount*) { /* do nothing by default */ }
};

Теперь мы создаем специальный класс для выполнения AddToBalance только на ChildAccount s.

class AddToBalance : public Visitor {

  public:
  AddBalance(string _nameOfTarget, int _balanceToAdd) :
    nameOfTarget(_nameOfTarget), balanceToAdd(_balanceToAdd) {}

  void Visit(ChildAccount* _child) { //overrides Visit only for ChildAccount nodes
    if(child->name == _name)
      child->addToBalance(_balance); //calls a function SPECIFIC TO THE CHILD
  }

  private:
    string nameOfTarget;
    int _balanceToAdd;
};

Некоторые изменения в исходном классе учетной записи.

class Account{
   vector<Account*> children; //assume ALL Account objects could have children; \
                              //for leaf nodes (ChildAccount), this vector will be empty
   string name;
   virtual int getBalance() =0; //generic base class has no implementation

   //no addToBalance function!

   virtual void Accept(Visitor* _visitor) {
     _visitor->Visit(this);
   }
};

Обратите внимание на Функция Accept() в классе Account, которая просто принимает посетителя* в качестве аргумента и вызывает функцию посещения этого посетителя на this. Именно здесь происходит волшебство. в этот момент тип this, а также Тип _visitor будут разрешены. Если this имеет тип ChildAccount и _visitor имеет тип AddToBalance, то функция Visit, которая будет вызвана в _visitor->Visit(this);, будет void AddToBalance::Visit(ChildAccount* _child).

Который просто так называется _child->addToBalance(...);:

class ChildAccount : public Account{
   int balance;
   virtual int getBalance() { return balance; }
   virtual void addToBalance(int amount) {
     balance += amount;
   } 
};

Если бы this в void Account::Accept() было a ParentAccount, то пустая функция Visitor::Visit(ParentAccount*) было бы вызвано, так как эта функция не переопределена в AddToBalance.

Теперь нам больше не нужно определять функцию addToBalance в ParentAccount:

class ParentAccount : public Account{
   virtual int getBalance() {
      int result = 0;
      for (int i = 0; i < children.size(); i++)
          result += children[i]->getBalance();
      return result;
   }
   //no addToBalance function
};

Вторая самая забавная часть заключается в следующем: поскольку у нас есть дерево, мы можем иметь общую функцию, определяющую последовательность посещений, которая решает, в каком порядке посещать узлы дерева:

void VisitWithPreOrderTraversal(Account* _node, Visitor* _visitor) {
  _node->Accept(_visitor);
  for(size_t i = 0; i < _node->children.size(); ++i)
    _node->children[i]->Accept(_visitor);

}

int main() {
  ParentAccount* root = GetRootOfAccount(...);

  AddToBalance* atb = new AddToBalance("pensky_account", 500);
  VisitWithPreOrderTraversal(atb, root);

};

Самая забавная часть-это определение вашего собственного посетителя, который делает гораздо более сложным операции (например, накопление сумм остатков только по всем дочерним счетам):

class CalculateBalances : public Visitor {

  void Visit(ChildAccount* _child) {

    balanceSum += _child->getBalance();

  }
  int CumulativeSum() {return balanceSum; }
  int balanceSum;
}

Концептуально, у вас нет дочерних и родительских учетных записей, но учетные записи и дерево объектов, из которых конечные узлы содержат указатель на фактические учетные записи.

Я бы предложил вам непосредственно представить эту структуру в коде:

class Account
{
public:
    int getBalance(); 
    void addToBalance(int amount);
// privates and implementation not shown for brevity
};


class TreeNode
{
public:
    // contains account instance on leaf nodes, and nullptr otherwise.
    Account* getAccount(); 

    // tree node members for iteration over children, adding/removing children etc

private:
    Account* _account; 
    SomeContainer _children
};

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