CODEWITHSUNDEEP
c#design-patterns
Ali
Ali

Reputation: 1286

Design decision - Factory vs Observer Pattern

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!

Upvotes: 3

Views: 1496

Answers (2)

Samy Arous
Samy Arous

Reputation: 6814

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.

Upvotes: 3

Adil
Adil

Reputation: 3268

Factory pattern will be fine if you want to create instance based on certain criteria.

If you are sure that you will use either SMS or Email sender then you can consider using Dependency Injection as well and let IMySender be resolved on runtime using any DI container. For example, StructureMap.

I am not sure about observer pattern, seems to be a bit complex.

Upvotes: 0

Related Questions