Java 提示：为API构建外观可能会变得又大又难看？

我正致力于为现有应用程序使用的第三方API构建一个外观。这个API绑定到一个外部服务，而且它很大，测试性很差。我正在研究如何包装它以进行测试（返回预先打包的结果，而不是实际调用外部服务），以及如何与实际的API实现分离，但是存在一些潜在的障碍，可能会使Facade构造几乎与现有API本身一样大。几个例子

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

教授中心课程相当简单。使用一些附加方法扩展和包装中心类的装饰器可以处理这个问题，尽管我不确定除了直接扩展中心类之外，这是否真的有任何优势。这将允许我们将一个实例传递给其他对象，以便所有调用也将使用修饰类。然而，这仍然使我们非常直接地依赖于实现。我想将其进一步解耦，但这可能意味着为100多个类构建门面需要大量的工作，其中一些类是在后台创建的，我们必须在代码中创建大量的门面，以便保存到外部服务。我们确实有这个API的源代码，但我不太愿意做任何重大修改，因为我们可能需要升级到更高版本

---

有什么建议可以让这一切尽可能地无痛，还是我注定要接受部分解决方案，或者为此花费大量时间？我以前没有机会创造这么大的正面，这有点让人望而生畏。是的，我们可以使用某种模拟框架进行测试，但这只是解决测试问题的部分解决方案，而不是长期支持和灵活性

你说你想建一个门面。这意味着您可以完全自由地以任何方式设计您的外观！我将从您的用例开始，并为那些只有的用例实现接口。您不必连接您提到的所有“超过200种方法”

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

• 适配器：将一个接口转换为另一个接口，以使其符合客户端的期望
• Decorator：通过包装原始代码，动态地向接口添加职责
• Facade：提供简化的界面

---

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

看看或当我遇到timesink时。我写了一个实用程序为我做这件事。