将“C”API包装到OO包装器中的设计问题

Question

我正在尝试构建一个面向对象的包装器，它将包装API规范;这包括许多结构，事件和API。 该API规范将每年进行修订，并发布新的规范;更新可能有更新的结构，事件和API。更新还将包括 对现有结构，事件和API的更新，API本身不会改变，但是它们将各种结构作为最终具有更新的参数

挑战

1. API规范只不过是下层的SDK， 我想要构建的也是一个SDK，但它将是一个对象 定位此SDK的包装器。
2. 要求是用户 想要对象和方法，没有像“C”这样的结构和API
3. 频繁的版本更改不应对高级别产生任何影响 应用程序，应与任何底层API无缝协作 版本
4. 较旧的应用程序应该适用于较新的API
5. 较新的应用程序应该适用于较旧的API

最后一个是一个棘手的问题，我的意思是新的应用程序，当它看到它的旧版本的SDK应该以某种方式将自己转换为旧版本的API

是否有任何设计模式可以帮助我完成这项任务，并将内部数据的频繁更改与实现向后兼容性和向前兼容性相结合？

操作系统：Windows  开发环境：Visual C ++

Answer 1

您的问题太高，无法通过设计模式负责。 您要求的是建筑原则。

这些应该基于您有充分根据的设计决策（“API使用版本控制向后兼容，因为......”），这反过来又基于您的要求（例如“旧版应用程序应该适用于较新的API”）。 / p>

调查一下（Joshua Bloch关于API设计的演示主题演讲）：

How to Design a Good API and Why it Matters

Answer 2

1）如果sdk API涉及手动资源分配，那么现在想到的只有：

RAII，或ctor，dtor资源管理：https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

2-5）确定您正在构建的API的功能分解，这可以通过SDK API的每个版本层表达。关于半正式函数分解的一些细节（在底部）：

http://jfeltz.com/posts/2015-08-30-cost-decreasing-software-architecture.html

然后，您可以获取生成的函数组合，并在必要时使它们成为可构造的对象。在了解所涉及的函数组合之前，不要担心最终的对象模型。这一开始很难，但相信我，它比迭代几种可能的对象模型设计要强大得多。

对于C ++，您可能需要对每个上游SDK API的版本方案执行#define预处理，除非您的sdk将其版本编码在某个文件中，这样您就可以执行dll加载（在在哪种情况下，这可能是工厂设计模式），但我怀疑你已经知道了。