强制从子类覆盖父类的所有虚函数

Question

我们将一个实现抽象类 IFunctionality 的对象包装在一个我们正在编写的也实现 IFunctionality 的类中。

IFunctionality 接口是在第三方代码中定义的，目前它只包含虚函数，其中大部分是纯虚函数。非纯虚函数通常有一个空实现，并在具体实现中被覆盖。 IFunctionality 没有任何成员变量（目前）。

我们的包装器看起来像这样：

class WrapperFunctionality : public IFunctionality
{
public:
    WrapperFunctionality(IFunctionality& pOriginal)
        : m_pOriginal(pOriginal)
    {
    }

    // We override all virtual functions and forward them to the original.
    void doX() override { m_pOriginal->doX(); }
    void doY() override { m_pOriginal->doY(); }
    // ...

    // Well, except a few functions that we specialize.
    // That's why we need the wrapper.
    void doSomethingSpecial() override { ... }
};

目前一切都很好。但是代码将来可能会静默地破坏。

问题 1：第三方代码可能会向 IFunctionality 添加新的非纯虚函数。它将未被检测到，我们将无法在原始对象中调用相应的函数。

问题 2：第三方代码可以将公共成员添加到 IFunctionality 并可以直接访问这些成员。我们也无法将这些修改转发给原始对象。

我想知道我们是否可以借助 static_assert 或一些模板魔法在编译时检测到这些问题。

问题 2 已在 How to detect if a class has member variables? 中讨论，但没有令人满意的解决方案。但在我看来，这不太可能发生（因为这些第三方开发人员似乎并不喜欢这个接口类的公共成员变量）。

但问题 1 更有可能发生。接口类已经有非纯虚函数，并且很可能得到新的。有没有办法强制我的类实现该类的所有虚函数（纯或非纯）？

---

为了澄清事情，让我对情况进行更具体的描述。

界面表示一个表面，可以在其上绘制具有给定属性的几何图形：

class ISurface
{
public:
    virtual void setColor(const RGB& color) = 0;
    virtual void setOpacity(float alpha) = 0;
    virtual void drawLine(...) = 0;
    virtual void drawCircle(...) = 0;
    // etc
};

具体的ISurface实现由第三方框架实例化，基于后端有多种实现。

我们的系统中有许多知道如何将自己绘制到 ISurface 的对象。我们不控制他们的draw 功能。对象可以来自第三方插件：

class IDrawableObject
{
public:
    virtual void draw(ISurface* pSurface) const = 0;
};

然后是IDrawableObject的可能实现，可能来自第三方代码：

class SomeObject : public IDrawableObject
{
public:
    virtual void draw(ISurface* pSurface) const override
    {
        pSurface->setColor(RGB(255, 0, 0));
        pSurface->drawLine(...);
        pSurface->setOpacity(0.7f);
        pSurface->fillCircle(...);
    }
};

在某些时候，我们希望通过覆盖它们的颜色或不透明度来更改这些第三方对象的视觉表示。我们可以挂钩到对对象进行绘图调用的过程：

// That function will be called by the framework
virtual void drawObjectToSurface(const IDrawableObject* pObject, ISurface* pSurface) override
{
    pSurface->setColor(m_overrideColor);
    pSurface->setOpacity(m_overrideAlpha);

    // Next line does not work as expected, because the object
    // overwrites our color and alpha before drawing itself
    //pObject->draw(pSurface); // does not work

    // Instead, we use a wrapper that blocks color and opacity writes
    BlockingSurfaceWrapper wrapperSurface(pSurface);
    pObject->draw(&wrapperSurface);
}

Answer 1

唯一不需要运行时开销或名副其实的 hack 和类似混乱的解决方案是编写一个 libclang 分析过程，以验证所有基本虚拟方法都已被覆盖，然后将此过程作为构建的一部分运行。有许多使用 libclang 实现的各种静态分析的在线示例。这是唯一可以扩展的解决方案，一旦您开始工作，您就可以在构建过程中添加各种其他分析，以强制执行其他策略或设计要求。从长远来看，这可能是唯一的出路。

在此期间，我不会为任何其他黑客行为而烦恼。在实施静态分析之前，您应该将此检查添加到您的手动代码审查清单中，并且它将被审查即将提交/合并到存储库的代码的人员捕获。如果您没有代码审查清单，或者更糟糕的是 - 不要审查合并请求 - 是时候开始了。

您将代码更改视为您无能为力的破坏性不可抗力是非常可疑的。这暗示您没有代码审查流程，因此生活暴露在天气的奇思妙想中。这就是你冻伤的原因，这就是项目最终失败的原因。您与我们分享的问题只是您在捆绑包中遇到的一大堆其他问题中的一小部分，当代码可以在没有第二双眼睛查看的情况下进行更改时，并且没有关于合并更改的规则。

评论将解决您的所有问题，以防万一：

1. 第三方代码可以向 IFunctionality 添加新的非纯虚函数 - 第三方代码应该是 git 存储库中的子模块，或者复制到存储库中。对第三方代码的任何更改都必须是代码审查过程的一部分，才会被清单项捕获。

2. 第三方代码可以将公共成员添加到 IFunctionality 并可以直接访问这些成员 - 同上，代码审查会发现这一点。

现在你问：审查第三方代码不是很疯狂吗？不是，因为您显然如此紧密地依赖该代码，所以它在功能上是您代码库的一个组成部分——当接口设计不佳时会发生这种情况。它不仅仅是一种依赖。您必须将其视为您为项目编写的任何其他代码。

生活中没有什么是免费的，当然审查需要时间 - 清单上的项目越多，它们就越拖累。一个空的清单并不意味着您可以摆脱评论：清单应该保持在最本质的部分，否则没有人会在确保合规的同时保持理智。但是现在您看到您有选择：您可以花时间进行更长的代码审查，或者您可以花时间学习使用 libclang。这是一个真正的游戏规则改变者 - 就在十多年前，行业实力的静态代码分析“构建块”库仅可用于大量资金，或者您必须向一家专门从事代码分析的公司支付费用才能将您的分析作为一个黑 -使用他们开发的工具来提供此类服务。

它要么扩展代码审查，要么实现静态分析。没办法。

Answer 2

我认为这两个问题都不能以可移植的方式解决，因为它们需要遍历基类属性。

第一个问题可以通过比较基类和子类的 vtable 并确保它们不共享任何地址来解决。请参阅gcc layout。当然，这是特定于编译器且不重要的，但您可能比编译器更频繁地更新库。

但我不明白重写某些虚拟方法如何保证包装器。您可以将它们标记为 final 并使用其他纯虚拟方法公开类似的接口。毕竟，如果pOriginal 自己覆盖它们会发生什么？你不理他们吗？我认为这种设计有问题。