c++ - 强制覆盖父类的所有虚函数，从子类

Question

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

IFunctionality 接口(interface)是在第三方代码中定义的，目前它只包含虚函数，其中大部分是纯虚函数。非纯虚函数通常有一个空实现，并在具体实现中被覆盖。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:第三方代码可以将公共(public)成员添加到 IFunctionality 并可以直接访问这些成员。我们也无法将这些修改转发给原始对象。

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

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

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

---

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

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

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

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

在此期间，我不会为任何其他 hack 而烦恼。在实现静态分析之前，您应该将对此的检查添加到您的手动代码审查 list 中，它会被审查即将提交/合并到 repo 的代码的人员发现。如果您没有代码审查 list ，或者更糟的是 - 不审查合并请求 - 现在是时候开始了。

如果您将代码更改视为您无力抵抗的破坏性不可抗力，这是非常可疑的。这暗示您没有代码审查流程，因此生活暴露在反复无常的天气中。这就是你被冻伤的原因，也是项目最终失败的原因。您与我们分享的问题只是您遇到的一大堆其他问题中的一个小问题，当代码可以在没有第二双眼睛注视的情况下更改时，没有关于合并更改的规则。

评论将解决您的所有疑虑，以防您不清楚:

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

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

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

生活中没有什么是免费的，当然，审查需要时间 - list 上的项目越多，它们就越拖沓。一个空的 list 并不意味着你可以去掉评论: list 应该保留在最基本的部分，否则没有人会在确保合规的同时保持理智。但是现在您看到您有选择:您可以花时间进行更长的代码审查，或者您可以花时间学习使用 libclang。它是一个真正的游戏规则改变者——就在十多年前，行业强大的静态代码分析“构建 block ”库只能花很多钱才能获得，或者你必须花钱请一家专门从事代码分析的公司来实现你的分析—— box 使用他们开发的工具来提供此类服务。

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