我相信最好的方法是通过依赖注入，但不是你描述的那样。而不是直接注入HttpClient，而是注入WeatherStatusService（或一些等效名称）。我将使用一种方法（在您的用例中）getWeatherStatus() 将其设为一个简单的界面。然后你可以用HttpClientWeatherStatusService 实现这个接口，并在运行时注入它。要对核心类进行单元测试，您可以选择通过使用您自己的单元测试要求实现WeatherStatusService 自己对接口进行存根，或者使用模拟框架来模拟getWeatherStatus 方法。这种方式的主要优点是：
- 不要破坏封装（因为更改为 SOAP 实现涉及创建
SOAPWeatherStatusService 并删除 HttpClient 处理程序）。
- 您已经分解了最初的单个类，现在有两个具有不同目的的类，一个类显式处理从 API 检索数据，另一个类处理核心逻辑。这可能是这样的流程：接收天气状态请求（来自更高层）-> 从 api 请求数据检索-> 处理/验证返回的数据->（可选）存储数据或触发其他进程对数据进行操作->返回数据。
- 如果出现不同的用例来利用这些数据，您可以轻松地重复使用
WeatherStatusService 实现。 （例如，也许您有一个用例来存储每 4 小时的天气状况（向用户显示当天发展的交互式地图），另一个用例来获取当前天气。在这种情况下，您需要两个不同的核心逻辑需求都需要使用相同的 API，因此让这些方法之间的 API 访问代码保持一致是有意义的）。
这种方法被称为六边形/洋葱结构，我建议在这里阅读：
或者这篇总结核心思想的帖子：
编辑：
进一步了解您的 cmets：
测试 HttpClientWeatherStatus 怎么样？忽略单元测试，否则我们必须找到一种方法来模拟 HttpClient 那里？
使用HttpClientWeatherStatus 类。理想情况下，它应该是不可变的，因此 HttpClient 依赖项在创建时被注入到构造函数中。这使得单元测试变得容易，因为您可以模拟HttpClient 并防止与外界的任何交互。例如：
public class HttpClientWeatherStatusService implements WeatherStatusService {
private final HttpClient httpClient;
public HttpClientWeatherStatusService(HttpClient httpClient) {
this.httpClient = httpClient;
}
public WeatherStatus getWeatherStatus(String location) {
//Setup request.
//Make request with the injected httpClient.
//Parse response.
return new WeatherStatus(temperature, humidity, weatherType);
}
}
返回的WeatherStatus“事件”在哪里：
public class WeatherStatus {
private final float temperature;
private final float humidity;
private final String weatherType;
//Constructor and getters.
}
那么测试看起来像这样：
public WeatherStatusServiceTests {
@Test
public void givenALocation_WhenAWeatherStatusRequestIsMade_ThenTheCorrectStatusForThatLocationIsReturned() {
//SETUP TEST.
//Create httpClient mock.
String location = "The World";
//Create expected response.
//Expect request containing location, return response.
WeatherStatusService service = new HttpClientWeatherStatusService(httpClient);
//Replay mock.
//RUN TEST.
WeatherStatus status = service.getWeatherStatus(location);
//VERIFY TEST.
//Assert status contains correctly parsed response.
}
}
你一般会发现在集成层中会出现很少的条件和循环（因为这些构造代表逻辑，所有的逻辑都应该在核心中）。正因为如此（特别是因为在调用代码中只有一个条件分支路径），有些人会争辩说这个类几乎没有点单元测试，并且它可以很容易地被集成测试覆盖，并且以一种不那么脆弱的方式。我理解这个观点，并且在集成层中跳过单元测试没有问题，但我个人无论如何都会对其进行单元测试。这是因为我相信集成域中的单元测试仍然可以帮助我确保我的类是高度可用的，并且是可移植/可重用的（如果它易于测试，那么它很容易在代码库的其他地方使用）。我还使用单元测试作为详细说明该类使用的文档，其优点是任何 CI 服务器都会在文档过期时提醒我。
这不是因为一个小问题而使代码臃肿，而这个小问题本可以通过使用反射的几行或简单地更改为封装私有字段访问来“修复”？
您在引号中加上“固定”这一事实充分说明了您认为这种解决方案的有效性。 ;) 我同意代码肯定有些臃肿，这起初可能令人不安。但真正的重点是制作一个易于开发的可维护代码库。我认为有些项目起步很快，因为他们通过使用黑客和狡猾的编码实践来“修复”问题以保持进度。由于压倒性的技术债务会导致需要数周甚至数月的大规模重构，因此生产力通常会停滞不前。
一旦您以六边形方式设置了一个项目，当您需要执行以下操作之一时，真正的回报就会出现：
更改您的集成层之一的技术堆栈。（例如，从 mysql 到 postgres）。在这种情况下（如上所述），您只需实现一个新的持久层，确保您使用来自绑定/事件/适配器层的所有相关接口。应该不需要更改核心代码或接口。最后删除旧层，在原地注入新层。
添加新功能。 通常集成层已经存在，甚至可能不需要修改即可使用。在上述getCurrentWeather() 和store4HourlyWeather() 用例的示例中。假设您已经使用上述类实现了store4HourlyWeather() 功能。要创建这个新功能（假设该过程从一个 restful 请求开始），您需要创建三个新文件。您需要在 Web 层中创建一个新类来处理初始请求，在核心层中需要一个新类来表示 getCurrentWeather() 的用户故事，并且在绑定/事件/适配器层中需要一个接口，该接口是核心类实现，并且 web 类已经注入到它的构造函数中。现在，一方面，是的，您已经创建了 3 个文件，而本来可以只创建一个文件，或者甚至只是将它附加到现有的 restful web 处理程序上。当然，您可以，在这个简单的示例中，它可以正常工作。只有随着时间的推移，层之间的区别才变得明显，重构变得困难。考虑一下将它附加到现有类的情况，该类不再具有明显的单一目的。你会怎么称呼它？怎么会有人知道在其中查找此代码？您的测试设置变得多么复杂，以至于您现在可以测试这个类，因为有更多的依赖项需要模拟？
更新集成层更改。 继续上面的示例，如果天气服务 API（您从中获取信息的位置）发生更改，那么您只需要在一个地方进行更改在您的程序中进行更改以再次与新 API 兼容。这是代码中唯一知道数据实际来自何处的地方，因此它是唯一需要更改的地方。
将项目介绍给新的团队成员。 有争议的一点，因为任何布局良好的项目都相当容易理解，但到目前为止，我的经验是大多数代码看起来都很简单并且可以理解。它实现了一件事，并且非常擅长实现那一件事。了解在哪里查找（例如）Amazon-S3 相关代码是显而易见的，因为有一整层专门用于与之交互，并且该层中没有与其他集成问题相关的代码。
修复错误。 与上述内容相关联，重现性通常是修复的最大步骤。所有集成层都是不可变的、独立的和接受明确的参数的优点是很容易隔离单个故障层并修改参数直到它失败。 （尽管同样，精心设计的代码也能很好地做到这一点）。
希望我已经回答了您的问题，如果您有更多问题，请告诉我。 :) 也许我会考虑在周末创建一个示例六边形项目并在此处链接到它以更清楚地证明我的观点。