我有以下数据结构:

class Element {
  std::string getType();
  std::string getId();
  virtual std::vector<Element*> getChildren();
}

class A : public Element {
  void addA(const A *a);
  void addB(const B *b);
  void addC(const C *c);
  std::vector<Element*> getChildren();
}

class B : public Element {
  void addB(const B *b);
  void addC(const C *c);
  std::vector<Element*> getChildren();
}

class C : public Element {
  int someActualValue;
}

/* The classes also have some kind of container to store the pointers and
 * child elements. But let's keep the code short. */

该数据结构用于生成无环有向图。 C 类充当包含代数任务实际数据的“叶子”。 A 和 B 包含其他信息，例如名称、类型、规则、我最喜欢的颜色和天气预报。

我想编写一个功能，其中会弹出一个窗口，您可以在现有结构中导航。在途中，我想用一些漂亮的流程图显示用户采取的路径，可以单击它返回到层次结构中。基于当前访问的图节点(可以是 A、B 或 C)，必须计算和显示一些信息。

我以为我可以制作一个 Element* 类型的 std::vector 并将最后一项用作我使用的事件元素。我认为这是一个非常好的方法，因为它利用了已经存在的继承并使我需要的代码非常小。

但是我有很多这样的情况:

Element* currentElement;

void addToCurrentElement(const C *c) {
  if(A *a = dynamic_cast<A*>(currentElement)) {
    //doSomething, if not, check if currentElement is actually a B
  }    
}

或者更糟:

vector<C*> filterForC's(A* parent) {
  vector<Element*> eleVec = parent.getChildren();
  vector<C*> retVec;
  for(Element* e : eleVec) {
    if (e.getType() == "class C") {
      C *c = dynamic_cast<C*>(e);
      retVec.append(c);
    }
  }
}

它绝对是面向对象的。它确实使用了继承。但感觉就像我只是把 OOP 给我的所有舒适感都扔掉了，并决定再次使用原始指针和位移位。谷歌搜索这个主题，我发现很多人说向上/向下转换是糟糕的设计或糟糕的做法。我完全相信这是真的，但我想确切地知道为什么。我无法更改大部分代码，因为它是一个更大项目的一部分，但我想知道在将来设计程序时如何应对这种情况。

我的问题:

1. 除了看起来很糟糕之外，为什么向上/向下类型转换被认为是糟糕的设计？
2. dynamic_cast 慢吗？
3. 有什么经验法则可以避免我上面解释的那种设计吗？

最佳答案

这里有很多关于 dynamic_cast 的问题。我只阅读了一些并且在我自己的代码中也不经常使用该方法，所以我的回答反射(reflect)了我对这个问题的看法而不是我的经验。小心。

(1.) Why is casting up/down considered bad design, besides the fact that it looks horrible?

(3.) Are there any rules of thumb how i can avoid a design like the one i explained above?

在阅读 Stroustrup C++ FAQ 时，imo 有一个中心信息:不要相信那些说从不 使用某种工具的人。相反，使用正确的工具来完成手头的任务。

然而，有时，两种不同的工具可能具有非常相似的用途，这里也是如此。您基本上可以通过 virtual 函数使用 dynamic_cast 重新编码任何功能。

那么什么时候 dynamic_cast 才是合适的工具呢？ (另见 What is the proper use case for dynamic_cast?)

• 一种可能的情况是，您有一个无法扩展的基类，但仍然需要编写类似重载的代码。使用动态转换，您可以无创地做到这一点。

• 另一种是你想保留一个接口(interface)，即纯虚基类，不想在任何派生类中实现相应的虚函数。

然而，通常情况下，您宁愿依赖虚函数——即使只是为了减少丑陋。此外，它更安全:动态转换可能会失败并终止您的程序，而虚拟函数调用(通常)不会。

此外，以纯函数的形式实现，当你添加一个新的派生类时，你不会忘记在所有需要的地方更新它。另一方面，代码中很容易忘记动态转换。

你的例子的虚函数版本

再举个例子:

Element* currentElement;

void addToCurrentElement(const C *c) {
  if(A *a = dynamic_cast<A*>(currentElement)) {
    //doSomething, if not, check if currentElement is actually a B
  }    
}

要重写它，在您的基础中添加一个(可能是纯的)虚函数 add(A*)、add(B*) 和 add(C *) 在派生类中重载。

struct A : public Element
{
     virtual add(A* c) { /* do something for A */ }
     virtual add(B* c) { /* do something for B */ }
     virtual add(C* c) { /* do something for C */ }
};
//same for B, C, ...

然后在你的函数中调用它或者写一个更简洁的函数模板

template<typename T>
void addToCurrentElement(T const* t)
{
    currentElement->add(t);
}

我会说这是标准方法。如前所述，缺点可能是对于纯虚函数，您需要 N*N 重载，其中 N 可能就足够了(比如，如果只有 A::add 需要特殊处理)。

其他替代方案可能使用 RTTI , CRTP模式、类型删除，可能还有更多。

(2.) Is a dynamic_cast slow?

当考虑整个网络状态的大多数答案时，是的，动态转换似乎很慢，请参见 here例如。 然而，我没有实际经验来支持或否定这一说法。

关于c++ - 通过继承层次结构进行 dynamic_casting 是不好的做法吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30924724/