我应该使用哪种设计模式来使3个对象松散耦合和封装？

Question

我试着看不同的设计模式来解决我正在处理的一个问题。我希望三个对象是松散耦合和封装的。

• 对象1：：用于公开持久化层的对象。
• 对象2: Rest模板服务对象:在REST上执行操作并包含针对不同端点的各种方法的对象。JSON被反序列化为专门针对此响应定制的Order类。
• 对象3: Rest模板服务对象:与对象2不同，它在不同的REST上执行操作。JSON被序列化为专门针对此响应定制的Order类。

我所面临的问题是，我希望能够松散地耦合这三个对象，从而更容易地添加新的rest模板服务对象或更改指定的存储库。稍后，我可能会添加授权，例如，您不能使用此服务对象，但可以使用服务对象3、4或5。目前，我有一个对象充当服务对象1和服务对象2的中间人。中间人对象包含存储库对象的实例变量。目前，中间人对象是紧密耦合到这三个对象。使这三个对象松散耦合的最佳方法是什么？我看了调解员的模式，但我不确定这是否是最好的办法。我正在练习设计模式，偶然发现了这个问题。

更多关于问题域的内容。本地存储的数据是生成的订单。服务对象是需要通知新订单的REST端点。这只是其中一个终点，但其他的是order X的cancel行项。因此，当创建新订单时，数据库将使用新的订单进行更新。在一天中的某个时间，使用服务对象在各个REST端点创建新的订单。

如果需要更多的信息，我将非常乐意包括它。我正在练习设计模式，我遇到了这个问题，所以我绝不是一个专家。

Answer 1

我认为兄弟姐妹的“战略模式”略近一点。中介者更多地是关于允许松散耦合的对象通过中介者彼此交谈。策略更多的是选择合适的松散耦合对象来满足请求。

在不同的模式剧本中，有“服务定位器”(Service)模式，这似乎也适合。

在实践中，您通常会创建一个服务接口，并创建与该接口相关联的具体服务。您可以利用DI容器作为服务定位器。

Answer 2

乍一看，这似乎是使用中介模式的一个很好的例子。

在这种模式中，中介管理同事对象之间的交互(可以是存储库和不同的rest模板)。最大的优势之一是，这可以将复杂的多到多的交互替换为一对多的交互，同时使同事们脱钩。