为API构建一个外观，可能会变得庞大而丑陋，提示？

Question

我正在努力构建我们在现有应用程序中使用的第三方API的外观。这个API与外部服务相关联，并且它的可测试性很大且很糟糕。我正在研究如何将其包装起来进行测试（返回预先打包的结果而不是实际调用外部服务）以及与实际API实现的一些脱钩，但是有一些潜在的障碍可能使Facade构建接近与现有API本身一样大。一些例子......

• “Central”类：这个类非常庞大，可能有近200种方法 在它的各种服务电话。我相信每次打电话给外部服务（或接近 它）在某些时候通过这个课程，有时我们直接 调用方法，有时通过方便的方法 其他物品。
• 对象：有很多对象/层次结构可以调用或使用Central类。其中一些只是可以轻松绕过的便捷方法，但有些方法没有通过直接调用Central类来调用的真正直接方式，至少没有一些相当广泛的拼凑。大多数人会将Central类的一个实例作为构造函数中的参数，或者使用setter方法。当然，我们可以为Central服务构建一个代理类，但仍然会使所有这些对象仍然直接绑定到Central类。为所有这些设置门面将是一个非常乏味的时间点。

使用Central类非常简单。使用一些额外的方法扩展和包装Central类的装饰器可以处理它，虽然我不确定这是否真的比直接扩展Central类更有优势。这将允许我们将实例传递给其他对象，以便所有调用也将使用修饰的类。但是，这仍然使我们直接与实现相关联。我想进一步解耦，但这可能意味着要为100多个课程建立一个Facade，其中一些是在幕后创建的，而且我们必须在我们的用于保存到外部服务的代码。我们确实拥有此API的来源，但我对进行任何重大修改犹豫不决，因为我们可能需要在未来升级到更高版本。

任何有关尽可能无痛的提示，或者我注定要么接受部分解决方案要么花费大量时间？我以前没有机会创建这么大的Facade，这有点令人生畏。是的，我们可以使用某种Mock框架进行测试，但这只是解决测试的部分解决方案，而不是长期支持和灵活性。

Answer 1

你说你想建立一个立面。这意味着您完全免费以您想要的任何方式设计您的立面！我将从您的用例开始，并为仅限实现界面。您不必连接您提到的所有“超过200种方法”。

您可以同时使用所有三种以下模式的组合：

• 适配器：将一个界面转换为另一个界面，使其与客户期望的相匹配
• 装饰器：通过包装原始代码动态地为界面添加责任
• Facade ：提供简化的界面

很抱歉，如果我错误地理解了你的意思。