Home/ Questions/Q 8055997
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T08:34:35+00:00

I have the following scenario: I have a QueueReader class that will be reading

  • 0

I have the following scenario:

I have a QueueReader class that will be reading messages from a queue. I also have some Senders like EmailSender and SMSSender, that will send these messages to clients using Email or SMS respectively. In the future more Senders can be added.

I can think of two ways of doing this and I am not sure which would be more beneficial.

Factory Pattern:

I can have a SenderManager that will use a SenderFactory to create the appropriate sender and then call its Send() method.

So the QueueReader upon reading a message will call the SenderManager’s Send() which will do the following:

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.

So, now if I have to add a new sender, I won’t have to change the QueueReader or the SenderManager. I will just add the new Sender and modify the SenderFactory.

Observer Pattern
In contrast to the above, I can have the QueueReader class implement an Event for NewMessage. Then have all my Senders subscribe to this event. The Sender will have access to the information that was in the Factory above to know if the message is for them.

The benefit of this would be any new Sender will simply have to subscribe to the event.

Now that I have written all of this down, I think the Observer Pattern is the cleaner approach…

However, if anyone has any insight or suggestion, please do share.

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would use an hybrid approach:

    SenderManager (The observer) would listen to the incoming messages and pick the right sender (or ask the SenderFactory to create one if needed). This has 2 benefits:

    First, you have control over which sender you pick (You don’t need to expose the SenderManager class) avoiding attack of type ManInTheMiddle. This is particularly important if you are going to expose an API for other developers to implement their own senders.

    Second, you can implement a sort of Garbage Collector and dispose of the sender that are no longer needed, instead of having multiple senders that are instantiated and monitoring your stream for nothing.

    You will need some kind of registration function to register the senders against the SenderManger.

    If you use an ObserverPattern, don’t forget to implement a default sender (can be a log system) in order to handle the unwanted messages.

    • 0