四种调解员

Question

我经常遇到在多对多关系中选择交互模式的问题。以下示例演示了实现同一目标的四种不同方法。

目标是将消息（广告）从一组实体（DeliveryCompany、College、Supermarket）传递到另一组实体（LazyBob、CleverAnn、FastJon）。显然，我们需要一个调解员 (AdBoard) 来帮助发布商将广告投放给合适的人，并帮助订阅者通知他们感兴趣的提案。

现在对广告做出回应是出于顾虑，但如果它很重要，我们可以假设将来有必要这样做。无论如何，这个响应必须有不同的路径（我们不是用另一个广告来响应广告，对吧？）

第一：

所有订阅者都必须实现描述其差异的接口。中介者被注入它们并为发布者实现一个接口。

第二：

第一个的反转版本。现在发布者实现了一个描述他们偏好的接口。它由为订阅者实现接口的中介使用。

第三：

Mediator 实现了两个接口：用于发送有针对性的广告（后端）和用于接收有关有趣主题的广告（前端）。后端注入所有发布者，前端注入所有订阅者。

第四：

第三个的反转版本。现在中介者被注入了许多实现其接口的发布者和订阅者。

问题：

这些变体是否同样成功地达到了目标？

在开发的早期阶段，可以毫无疑问地选择每一个，对吗？如果不是，选择的算法是什么？

Answer 1

鉴于您希望最大限度地减少耦合，理想情况下，公司和求职者只需使用AdBoard 的接口，但他们不需要任何结构更改。

但是，如果 JobSeeker 可以订阅是必不可少的（并且您现在必须对此进行建模），那么您需要 IAdSubscriberInterface，而 AdBoard 需要聚合订阅者。

如果求职者在有时间的时候只是在看AdBoard，那么AdBoard 不需要对求职者一无所知。

除非有某种业务关系，否则AdBoard 也可能不需要了解有关 AdPublishers 的任何信息。

图片中缺少的是广告。 AdBoard 聚合广告。广告可能需要有关 AdPublisher 的一些信息。它可以持有与 AdPublisher 的关联。 或者，如果您想进一步减少耦合，只需在创建时将公司名称等所需信息复制到广告中，就像纸质广告一样。