我正在努力为我们与现有应用程序一起使用的第三方 API 构建外观。此 API 与外部服务相关联，而且它的可测试性很大而且很糟糕。我正在研究包装它以进行测试的方法（返回预先打包的结果，而不是实际调用外部服务）以及与实际 API 实现脱钩，但有一些潜在的障碍可能使 Facade 构造几乎与现有 API 本身一样大。举几个例子...
- “中心”类：这个类非常庞大，其中可能有近 200 个用于各种服务调用的方法。我相信每次调用外部服务（或靠近它）都会在某个时候通过这个类，有时当我们直接调用内部方法时，有时通过其他对象中的便利方法。
- 对象：有很多对象/层次结构调用或利用 Central 类。其中一些只是可以轻松绕过的便捷方法，但有些没有真正直接通过直接调用 Central 类来调用的方法，至少在没有一些相当广泛的修补工作的情况下并非如此。大多数将 Central 类的实例作为构造函数中的参数或具有 setter 方法。当然，我们可以为 Central 服务构建一个代理类，但这仍然使所有这些对象仍然直接绑定到 Central 类。为所有这些设置一个门面将是一个非常乏味的消遣。
Central 类的外观相当简单。使用一些额外的方法扩展和包装 Central 类的装饰器可以处理这个问题，尽管我不确定这是否真的比直接扩展 Central 类有任何优势。这将允许我们将实例传递给其他对象，以便所有调用也将使用装饰类。然而，这仍然使我们与实现非常直接地联系在一起。我想进一步解耦它，但这可能意味着为 100 多个类建立一个 Facade 需要大量的工作，其中一些是在幕后创建的，还有很多我们必须在我们的保存到外部服务的代码。我们确实有这个 API 的源代码，但我不愿意做任何重大修改，因为我们可能需要升级到以后的版本。
有什么技巧可以让这个过程尽可能轻松，还是我注定要接受部分解决方案或在这方面花费大量时间？我以前没有机会创建这么大的门面，这有点令人生畏。是的，我们可以使用某种 Mock 框架进行测试，但这只是解决测试问题的部分解决方案，而不是长期支持和灵活性。