哪个设计模式最好地描述了我的例子中的行为?

Question

下面的伪示例是一个促进轮询过程、存储结果并将其保存到DB的类。我的理解是，这将被视为中介模式，因为它促进了对象之间的通信，否则这些对象将在没有它的情况下耦合。这是准确的吗?还是有另一种模式可以更好地解释这种行为?谢谢你！

public class StatusPoller
{
public void Poll()
{
foreach(User user in users)
{
string accessToken = oAuthClient.Authenticate(user);   // Authenticate
List<status> statuses = pollingClient.PollStatus(accessToken);   // Poll for status
Store(statuses);   // Store statuses in DB
}
Message.Dispatch(5)  // Dispatch a new message on a delay
}
}

Answer 1

kind，

中介模式要解决的问题是

We want to design reusable components, but dependencies between the potentially reusable pieces demonstrates the "spaghetti code" phenomenon (trying to scoop a single serving results in an "all or nothing clump").

所以当StatusPoller注入和处理它所有的依赖时，比如oAuthClientpollingClient和dbContext(可能在Store方法中)

我们正在降低所有这些对象之间通信的复杂性。

中介模式用于降低多个对象或类之间的通信复杂性。此模式提供了一个中介类，该中介类通常处理不同类之间的所有通信，并支持通过松耦合轻松维护代码。

所以基本上你的StatusPoller是作为具体的调解人

Answer 2

这不是任何特定的设计模式，这是非常好的。它只是一个方法。并非每个方法都需要或应该是设计模式。更具体地说，将A --> B转换为A --> C --> B不是中介。如果是这样，那么每个web应用程序的服务层将成为控制器和dao之间的中介。中介者将蜘蛛网转换成这样，

A —→ C
↘ ↙↗ ↖↘
D ←—→ E
↖ B ↗

放到这样的设计中

A        B        C
↘       ↓      ↙↗
M e d i a t o r
↙↗       ↑↓
D         E

，其中没有对象彼此直接通信，所有(双向)通信都通过中介进行。

这实际上是一个危险的模式，因为，正如你可能从图中猜到的那样，它非常容易使中介者成为一个好对象。纪律是必要的，以防止业务逻辑潜入中介，并将其职责仅限于消息传递。

Answer 3

它可以是中介者模式，这取决于StatusPoller如何接收和分派对它所中介的类的调用。但这看起来像是Facade模式的实现，它允许您将对各种对象的多个方法的调用减少为对StatusPoller.Poll()方法的单个调用。