如何为遗留 API/框架实现大量复杂的包装器（C++ 宏与 C++ 模板与代码生成器）？

Question

我们使用使用 VC6 编译器用 C++ 实现的非常旧的遗留系统。现在我们正在重构代码。我们还切换到VC9编译器。

我们使用外部专有框架，它也是遗留代码并且不可进行单元测试。为了使我们的代码单元可测试，我们引入了框架类的接口和包装器（提示：请参阅 Martin Fowler 的“使用遗留代码”）：

现在我们依赖于接口。包装器调用框架方法，我们可以愉快地在单元测试中使用模拟。

这里我们遇到了我们的问题......

框架类包含许多需要包装和模拟的方法。为了实现这一目标，我们的供应商团队编写了一个 API，它使用 C++ 宏生成接口、包装器和模拟实现。

包装器头文件示例：

class PlanWrapper : public IPlan
{
  // ... 
  WRP_DECLARE_DEFAULTS(FrameworkPlan); // macro
  WRP_DECLARE_CSTR_ATTR(FrameworkPlanLabel); // macro
  // ...
};

宏 WRP_DECLARE_CSTR_ATTR 定义如下：

#define WRP_DECLARE_CSTR_ATTR(AttrName) \
    virtual bool set##AttrName (LPCTSTR Value_in); \
    virtual bool get##AttrName (CString& Value_out); \
    virtual bool unset##AttrName (); \
    virtual bool isSet##AttrName ()

包装器 cpp 文件示例：

#include "StdAfx.h"

using namespace SomeNamespace;

WRP_IMPLEMENT_MODDICOM_DEFAULTS(FrameworkPlan)
WRP_IMPLEMENT_W_CSTR_ATTR (FrameworkPlan,FrameworkType1, FrameworkPlanLabel)
// ...

宏 WRP_IMPLMENT_W_CSTR_ATTR 定义如下：

#define WRP_IMPLEMENT_W_CSTR_ATTR(ClassName,AtrTypeObj,AttrName) \
    bool ClassName##Wrapper::set##AttrName (LPCTSTR Value_in) { \
            AtrTypeObj aValue = Value_in; \
        FrameworkLink<ClassName> convertedObj = NULL_LINK; \
        framework_cast(convertedObj, m_Object); \
        return convertedObj != NULL_LINK ? \
                       convertedObj->set##AttrName (aValue) : false; \
    }
    // ...

我们有一堆更复杂的东西，但我想您已经明白了。

API 的问题在于它极其复杂、不可读、不可调试、不可测试。

我们希望提出一个更好的机制来实现同样的目标。我们的想法是，我们使用新编译器附带的一些高级功能，如高级模板、类型列表、特征等。

使用模板，我们几乎可以实现我们的目标，但我们受困于方法名称。我们可以概括类型，但是我们如何处理属性名称？

我们还考虑创建一个自动生成包装器+接口+模拟代码的工具。然而，我们外部框架的API极其复杂，编写这样的工具成本非常高。

您认为解决此类问题的最佳方法是什么？也许您已经处理过类似的事情并且可以提供很好的提示？我们期待看到您的答案！

Answer 1

我想我会使用代码生成工具。我可能会制作一些简单的实用程序：一个用于生成与遗留框架的类相对应的接口，一个用于生成包装器，一个用于生成模拟对象（或至少一个骨架）。

这意味着有某种方法来解析遗留框架的代码。我会看看 Clang，或者简单地运行 ctags 在源文件上并处理生成的标签。

Answer 2

使用抽象工厂代替宏来解决这个问题。

class IApiFactory{
 virtual ISomeApi1* getApi1() =0;
 virtual ISomeApi2* getApi2() =0;
 .....
};

在为您的 Normal api 和 moc api 实现此接口并将工厂实例传递到您的系统后，如下所示：

MySystem system( new NormalApiFactory );

或

MySystem system( new MocApiFactory );

您的系统必须声明为：

class MySystem{
public:
  MySystem( IApiFactory* factory );
};

在您的工厂中，您将返回正常 api 实现或 moc 对象。
当然，您可以从根工厂返回工厂“这将返回其他工厂或对象”。

Answer 3

如果代码库足够大（即数十万行 C++），并且可以使用 GCC（最近的版本，即4.6）您可以也许考虑制作一个特定的GCC插件，或者MELT 扩展。 （MELT 是扩展 GCC 的高级领域特定语言）。然而，这种GCC 定制需要付出大量的努力（数周而不是数小时的工作）。

Answer 4

我喜欢代码生成器。您可能会创建一个包含所有要包装的内容的字典，这需要时间，然后使用一个简单的工具来生成代码。除了代码之外，您还可以获得遗留系统的清晰参考，以及稍后替换它的指南。

Answer 5

我们的DMS软件重组工具包是一个程序转换工具，它读取源代码并执行对其进行任意变换。

DMS 及其 C++ 前端 （支持 VC6 和更现代的 Visual Studio），它可能用于读取要模拟的组件的头文件，并生成模拟。

DMS 已用于对 C++ 代码进行大规模转换，特别是涉及接口更改和以各种方式重新排列接口。请参阅我的一篇技术论文，
通过自动程序转换重新设计 C++ 组件模型。

Answer 6

有一种方法可以以完全受控的方式构建代码生成，并且仍然保持生成您需要的困难 API 内容的所有自由。

如果您使用 Visual Studio（至少 2005，但最好是 2008 或 2010），您可以使用 T4 团队提到的结构化代码生成方式 - 仅基于 T4 和 XML：

http://blogs.msdn.com/b/t4/archive/2011/11/30/some-nice-new-getting-started-with-t4-videos.aspx

我我是该 ADM 方法的创新者和首席架构师，也是该博客 http://abstractiondev.wordpress.com/

不幸的是，我没有具体的案例可以链接来匹配您的案例，但我很高兴为您提供解决方案（如果您希望造福社区，发布一个案例）。