设计决策 - 工厂与观察者模式

本文关键字：观察者模式 工厂 决策 | 更新日期: 2023-09-27 18:36:01

我有以下情况：

我有一个 QueueReader 类，它将从队列中读取消息。我还有一些发件人，如EmailSender和SMSSender，它们将分别使用电子邮件或SMS将这些信息发送给客户端。将来可以添加更多发件人。

我可以想到两种方法来做到这一点，但我不确定哪种方法更有益。

工厂模式：

我可以有一个 SenderManager，它将使用 SenderFactory 来创建适当的发送器，然后调用其 Send（） 方法。

因此，QueueReader 在阅读消息时将调用 SenderManager 的 Send（），它将执行以下操作：

IMySender sender = SenderFactory.CreateSender()
sender.Send()
//I have the information to create the proper Dispatcher in the 
//factory based upon the message but I have omitted it for brevity.

所以，现在如果我必须添加新的发件人，我就不必更改 QueueReader 或 SenderManager。我将只添加新的发送器并修改发送器工厂。

观察者模式与上述相反，我可以让 QueueReader 类实现 NewMessage 的事件。然后让我的所有发件人订阅此事件。发件人将有权访问上述工厂中的信息，以了解该消息是否适合他们。

这样做的好处是任何新的发件人只需订阅该事件。

现在我已经写下了所有这些，我认为观察者模式是更干净的方法......

但是，如果有人有任何见解或建议，请分享。

谢谢！

设计决策 - 工厂与观察者模式

我会使用混合方法：

SenderManager（观察者）将侦听传入的消息并选择正确的发件人（或者如果需要，请SenderFactory创建一个）。这有两个好处：

首先，您可以控制选择哪个发件人（您不需要公开 SenderManager 类），避免 ManInTheMiddle类型的攻击。如果您要公开一个 API 供其他开发人员实现他们自己的发送者，这一点尤其重要。

其次，您可以实现一种垃圾回收器并释放不再需要的发送程序，而不是实例化多个发送器并无偿监视您的流。

您将需要某种注册功能来针对发件人管理器注册发件人。

如果使用 ObserverPattern，请不要忘记实现默认发送方（可以是日志系统）来处理不需要的消息。

如果要根据某些条件创建实例，工厂模式将很好。

如果您确定将使用短信或电子邮件发件人，那么您也可以考虑使用依赖关系注入，并让 IMySender 在运行时使用任何 DI 容器解析。例如，StructureMap。

我不确定观察者模式，似乎有点复杂。

相关文章：