c++ - API抽象层——避免API接口(interface)混用

Question

我一直在计划为我的渲染引擎编写一个 API 抽象层。我要包括的两个 API 是 D3D11 和 D3D12。因此，我开始为每个 API 编写一些接口(interface)及其各自的实现。

以下代码片段对此进行了举例说明:

class IDevice
{
    //... (pure) virtual methods
};

class CD3D11Device : public IDevice
{
    //... virtual method implementations
};

class CD3D12Device : public IDevice
{
    //... virtual method implementations
};

到目前为止一切顺利。现在到实际问题:如果我有另一个接口(interface)，其方法需要 IDevice* 作为参数，我如何确保传递“正确”的设备？

class ISomeClass
{
public:
    virtual void foo(IDevice* pDev) = 0;
};

class CD3D11SomeClass : public ISomeClass
{
public:
    virtual void foo(IDevice* pDev) override
    {
        // should only be passed CD3D11Device
    }
};

class CD3D12SomeClass : public ISomeClass
{
public:
    virtual void foo(IDevice* pDev) override
    {
        // should only be passed CD3D12Device
    }
};

我知道我可以每次都在 IDevice* 指针上调用 dynamic_cast 并检查 nullptr 但这既乏味又昂贵在性能方面。

这个问题有什么优雅的解决方案吗？你们中有人知道专业/商业游戏引擎如何应对吗？

Answer 1

您将无法将 D3D11 和 D3D12 抽象在一起，除非您在抽象方面比仅仅包装它们的接口(interface)走得更远。他们的设计太对称了。你需要的是设计一个单一的高度抽象的渲染引擎接口(interface)。 Material、Image 或 Model 之类的东西应该是 Scene 或 RenderList 之类的东西的严格底部。

至于在单个应用程序中支持多个图形 API，你在这里弄错了，如果你有 D3D12，则在 D3D11 代码路径中没有意义，选择应该是 D3D11/GL 而不是 D3D12/Vulkan。这不是因为 API 相似，而是因为您的应用程序需要的功能集。

请注意，D3D12 并不是要取代 D3D11，前者存在于 1% 的应用程序中，例如 AAA 游戏或大型数据集上的重型 GPGPU。如果您还不是 D3D11 的专家并且不知道为什么您必须使用 D3D12，请不要使用它!