对于这种情况，您会使用中介模式吗？

Question

我想知道您是否会在下面的场景中使用中介模式。

首先，程序必须调用API，并将此响应保存在某个地方(可以是数据库、文件、博客存储等等)。

我认为这里涉及两项责任：

1. 从API中提取数据，以及
2. 把它放在仓库里。

每个责任都有一个类(试图遵循单一责任原则)；两个类都不能直接交互(API的客户端类必须不知道它们的响应是持久化的，持久化类必须不知道持久化的模型/实体来自API)。因此，中介应该出现在这里:中介应该协调两个类的实例之间的交互，并完成程序的目的。

我正试图最大限度地提高类的凝聚力，并确保两个类之间的耦合程度很低(实际上是责任)。通过这样做，我可以更改为任何我想要的API，并坚持在我想要的地方。

所以问:你们认为我可以通过实现中介模式来实现这一点吗？还是有更好的方法来实现这一点？我完全愿意接受任何建议！！

Answer 1

通过松散的解释，您的应用程序是中介。本质上，您只需要封装对服务的访问，以及封装对存储的访问。应用程序调用服务并解释结果，将数据放置在存储组件中。因此，为中介添加一个特殊的类可能会导致过度，因为您的应用程序已经具备了这个角色。不过不疼。

我看到创建中介类的主要优点是用于单元测试：

• 创建用于调用服务和存储数据的接口。
• 您创建了使用这些接口的中介。
• 您可以编写模拟这些端点的测试，并验证数据准备是否正确。

整个交换现在是以一种孤立的方式测试的，而不实际调用外部服务和存储部分。

Answer 2

我觉得你不应该在这里使用中介模式。mediator模式要求对象将它们的交互委托给中介。但是，调用API和执行持久化的两个类在用例中都没有对中介的任何引用。API类和持久类不可能在不引用中介的情况下调用中介。

我建议这样使用桥型：

使用此模式：

• 您可以通过实现DataPersister接口来添加更持久的机制。
• 您可以通过扩展AbstractApiFetcher抽象类来支持更多的API。
• 您的API类只知道DataPersister接口。他们不知道这些接口是如何实现的(本地文件、数据库、.)。