Добавление виртуальных функций, не изменяя исходные классы

(Я предлагаю решение дальше ... терпите ...)

Один из способов (почти) решить вашу проблему - использовать шаблон проектирования Visitor. Примерно так:

class DrawVisitor
{
public:
  void draw(const Shape &shape); // dispatches to correct private method
private:
  void visitSquare(const Square &square);
  void visitCircle(const Circle &circle);
};

Затем вместо этого:

Shape &shape = getShape(); // returns some Shape subclass
shape.draw(); // virtual method

Вы бы сделали:

DrawVisitor dv;
Shape &shape = getShape();
dv.draw(shape);

Обычно в шаблоне посетителя вы реализуете метод draw следующим образом:

DrawVisitor::draw(const Shape &shape)
{
  shape.accept(*this);
}

Но это работает, только если иерархия Shape была разработана для посещения: каждый подкласс реализует виртуальный метод accept , вызывая соответствующий метод visitXxxx для Visitor. Скорее всего, он не был предназначен для этого.

Не имея возможности изменить иерархию классов, чтобы добавить виртуальный метод accept в Shape (и все подклассы), вам нужен другой способ отправки в правильный draw метод. Один наивный подход таков:

DrawVisitor::draw(const Shape &shape)
{
  if (const Square *pSquare = dynamic_cast<const Square *>(&shape))
  {
    visitSquare(*pSquare);
  }
  else if (const Circle *pCircle = dynamic_cast<const Circle *>(&shape))
  {
    visitCircle(*pCircle);
  }
  // etc.
}

Это будет работать, но использование dynamic_cast в таком случае снижает производительность. Если вы можете себе это позволить, это простой подход, который легко понять, отладить, поддерживать и т. Д.

Предположим, существует перечисление всех типов фигур:

enum ShapeId { SQUARE, CIRCLE, ... };

и существует виртуальный метод ShapeId Shape :: getId () const = 0; , который каждый подкласс должен переопределить, чтобы вернуть свой ShapeId . Затем вы можете выполнить отправку, используя массивный оператор switch вместо if-elsif-elsif из dynamic_cast s. Или, возможно, вместо переключателя используйте хеш-таблицу.В лучшем случае эту функцию сопоставления можно разместить в одном месте, чтобы можно было определять несколько посетителей без необходимости каждый раз повторять логику сопоставления.

Так что, вероятно, у вас тоже нет метода getid () . Печалька. Как еще можно получить уникальный идентификатор для каждого типа объекта? RTTI. Это не обязательно элегантно или надежно, но вы можете создать хеш-таблицу указателей type_info . Вы можете построить эту хеш-таблицу в некотором коде инициализации или построить ее динамически (или и то, и другое).

DrawVisitor::init() // static method or ctor
{
  typeMap_[&typeid(Square)] = &visitSquare;
  typeMap_[&typeid(Circle)] = &visitCircle;
  // etc.
}

DrawVisitor::draw(const Shape &shape)
{
  type_info *ti = typeid(shape);
  typedef void (DrawVisitor::*VisitFun)(const Shape &shape);
  VisitFun visit = 0; // or default draw method?
  TypeMap::iterator iter = typeMap_.find(ti);
  if (iter != typeMap_.end())
  {
    visit = iter->second;
  }
  else if (const Square *pSquare = dynamic_cast<const Square *>(&shape))
  {
    visit = typeMap_[ti] = &visitSquare;
  }
  else if (const Circle *pCircle = dynamic_cast<const Circle *>(&shape))
  {
    visit = typeMap_[ti] = &visitCircle;
  }
  // etc.

  if (visit)
  {
    // will have to do static_cast<> inside the function
    ((*this).*(visit))(shape);
  }
}

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

И последнее, что я добавлю: независимо от того, как вы решите выполнять отправку, вероятно, имеет смысл создать базовый класс посетителя:

class ShapeVisitor
{
public:
  void visit(const Shape &shape); // not virtual
private:
  virtual void visitSquare(const Square &square) = 0;
  virtual void visitCircle(const Circle &circle) = 0;
};