Replacing Switch Statements with the Factory Pattern in C#
Milan Jovanović
32,104 views
My annual spring sale is now live. Check it out: https://www.milanjovanovic.tech/sprin...
Get the source code for this video here → https://the-dotnet-weekly.kit.com/fac...
Want to master Clean Architecture? Go here: https://dub.sh/clean-architecture
Want to master Modular Monoliths? Go here: https://dub.sh/modular-monolith
Join the .NET Architects Club: https://www.skool.com/mj-tech-communi...
Get the 2026 .NET Developer roadmap here → https://the-dotnet-weekly.ck.page/202...
What happens when one service becomes responsible for creating dependencies, reading configuration, selecting implementations, and executing business logic?
You end up with code that is harder to test, harder to extend, and harder to maintain.
In this tutorial, I’ll refactor a messy NotificationService that supports email, SMS, and Slack notifications using the Factory Pattern in .NET.
We’ll clean up the initial implementation, extract notification senders behind an interface, introduce a factory abstraction, and wire everything together with dependency injection.
You’ll learn how to:
Recognize when object creation is making your service too complex
Remove duplicated logic and replace magic strings with enums
Encapsulate notification implementations behind INotificationSender
Implement a factory using a dictionary-based approach
Use .NET keyed services for cleaner dependency resolution
Extend the system with a new notification channel
Understand the difference between the Factory and Strategy patterns
By the end, our original service becomes much smaller, easier to test, and easier to extend without adding more conditional logic.
Check out my courses:
https://www.milanjovanovic.tech/courses
Read my Blog here:
https://www.milanjovanovic.tech/blog
Join my weekly .NET newsletter:
https://www.milanjovanovic.tech
Chapters
20 Comments
My annual spring sale is now live. Check it out: https://www.milanjovanovic.tech/spring-sale-2026?utm_source=YouTube&utm_campaign=spring_sale_2026
This delegate can then be used as a dependency in the dependent service thus removing the need for a pass through factory.
Also this keeps the logic for creating instances at the composition root.
But one thing, that confused me - in another video a few weeks ago, you mentioned to use the result pattern over throwing exceptions - but in the "createsender" method you throw an exception for a case I would say is a pretty "common" case.
Maybe you or someone else could explain this to me.
Thanks
Listening to the audio in my language helps me a lot in understanding all the content.
e.g., for the email channel you might want to use a specific email template; for the slack channel, you might want to route specific messages to a specific slack channel, etc. etc.. Technically, you could use an extra parameter for that, but then you've defeated the purpose of using a generic interface in the first place. I guess you could use an abstract class (or record) with a subclass for each subtype in stead of the enumeration then pattern match on those to select the correct implementation.
The explanation of the factory pattern itself was spot on though.
Thanks!
that looks really clean. I would like to take a look at the code. Could you please share a link to the code?
Thanks in advance!
at that point the code is separated and adding a new method is just adding a new enum, new logic in the old switch, and a new class to handle it... but at that half way point it feels like now we're adding more lines of code with no real gain... but... again... i'm not a pro... i just code for fun...
Replacing Switch Statements with the Factory Pattern in C#
Milan Jovanović
32,104 views
My annual spring sale is now live. Check it out: https://www.milanjovanovic.tech/sprin...
Get the source code for this video here → https://the-dotnet-weekly.kit.com/fac...
Want to master Clean Architecture? Go here: https://dub.sh/clean-architecture
Want to master Modular Monoliths? Go here: https://dub.sh/modular-monolith
Join the .NET Architects Club: https://www.skool.com/mj-tech-communi...
Get the 2026 .NET Developer roadmap here → https://the-dotnet-weekly.ck.page/202...
What happens when one service becomes responsible for creating dependencies, reading configuration, selecting implementations, and executing business logic?
You end up with code that is harder to test, harder to extend, and harder to maintain.
In this tutorial, I’ll refactor a messy NotificationService that supports email, SMS, and Slack notifications using the Factory Pattern in .NET.
We’ll clean up the initial implementation, extract notification senders behind an interface, introduce a factory abstraction, and wire everything together with dependency injection.
You’ll learn how to:
Recognize when object creation is making your service too complex
Remove duplicated logic and replace magic strings with enums
Encapsulate notification implementations behind INotificationSender
Implement a factory using a dictionary-based approach
Use .NET keyed services for cleaner dependency resolution
Extend the system with a new notification channel
Understand the difference between the Factory and Strategy patterns
By the end, our original service becomes much smaller, easier to test, and easier to extend without adding more conditional logic.
Check out my courses:
https://www.milanjovanovic.tech/courses
Read my Blog here:
https://www.milanjovanovic.tech/blog
Join my weekly .NET newsletter:
https://www.milanjovanovic.tech
Chapters