我有以下情况：
我有一个QueueReader类，它将从队列中读取消息。我还有一些发件人，如EmailSender和SMSSender，它们将分别使用电子邮件或短信将这些消息发送给客户。将来可以添加更多发件人。
我可以想到两种方法，我不确定哪种方式更有益。
工厂模式：
我可以有一个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。我将添加新的Sender并修改SenderFactory。
观察者模式 与上面相反，我可以让QueueReader类为NewMessage实现一个Event。然后让我的所有发件人订阅此活动。发件人可以访问上面工厂中的信息，以了解该消息是否适合他们。
这样做的好处是任何新发件人都只需订阅该活动。
现在我已经写下了所有这些，我认为观察者模式是更清洁的方法......
但是，如果有人有任何见解或建议，请分享。
谢谢！
答案 0 :(得分：2)
我会使用混合方法：
SenderManager（观察者）将收听传入的消息并选择正确的发送者（或者如果需要，请让SenderFactory创建一个）。这有两个好处：
首先，您可以控制您选择的发件人（您不需要公开SenderManager类），避免类型为ManInTheMiddle的攻击。如果您要为其他开发人员公开API以实现他们自己的发件人，这一点尤为重要。
其次，您可以实现一种垃圾收集器并处理不再需要的发件人，而不是让多个发件人实例化并监控您的流。
您需要某种注册功能才能针对SenderManger注册发件人。
如果您使用ObserverPattern，请不要忘记实现默认发件人（可以是日志系统）以处理不需要的邮件。
答案 1 :(得分：0)
如果要根据特定条件创建实例，则工厂模式将正常。
如果您确定要使用SMS或电子邮件发件人，那么您也可以考虑使用依赖注入，并使用任何DI容器在运行时解析IMySender。例如，StructureMap。
我不确定观察者模式，似乎有点复杂。