C# Design Patterns: The Factory Pattern
Design Patterns are important! When we face common problems they help guide our solution in the right direction. They’re not a magic bullet, but it’s wise to learn from the opinions of other (probably smarter) developers.
I’ve published an article talking about the Strategy Pattern, which I will reference at the end of this article. I’m solving the same problem with both patterns, I think it would be worth your time to compare both solutions.
Order Summary
Lets say that you’re a developer working on an ecommerce application. Every time something is purchased, a summary of that purchase is sent downstream to which ever company is selling that item.
A pretty simple summary, identifying which Vendor sold that item. The only complexity is that LawnChairCo receives XML, while MagicCubeInc and BestComputersInc receives JSON.
You could create a different API client, one that supports XML, one that supports JSON.
You could use the Strategy Pattern.
But lets see what your solution might look like if you used the Factory Pattern.
Factory Pattern
Wikipedia defines the Factory Pattern as “the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created.”
The Factory Pattern helps abstract away the details of creating an object we need. It now becomes the factory’s responsibility of deciding what object to create and how to create it.
In our case we need to generate a HTTP body in either XML or JSON. Lets create a factory to do that.
Our OrderSummary has Vendor information. That lets our BuildContent() method build the appropriate HttpContent for the specific Vendor we need. XML for LawnChairCo and JSON for the rest. If we onboard new vendors in the future with different requirements, adding additional logic to the Factory Pattern is simple.
Then lets look at our API Client and how it uses the factory.
It just calls with Factory with the orderSummary object. Then sends whatever is created to the appropriate uri.
Our ApiClient isn’t aware that some order summaries are generating XML and others JSON. That’s not it’s responsibility. It’s responsibility is to create the Http connection and send the message downstream. It’s the responsibility of the Factory to generate the appropriate message for the given Vendor.
This keeps our ApiClient thin and it’s responsibilities to a minimum.
Factory v Strategy
As mentioned earlier my article about Strategy Pattern solve the almost identical problem. At a high level the Factory and Strategy pattern can seem very similar. But there are some details that do distinguish them:
1. The Factory contains to logic to generate every possible class needed. Whereas with the Strategy pattern, creation is usually hidden behind an interface. Every different strategy is usually a new class which implements the interface.
If you had 10 different scenarios, for the Factory Pattern it’s still 1 class, but with the Strategy Pattern it’s 10 classes. Lots of classes makes it harder to see and compare logic across the different scenarios. Not impossible, but not as convenient as everything being in one class.
2. With our Factory Pattern example the data drives the decision on which class to create. But with the Strategy Pattern the system drives the decision on which interface to inject, usually through dependency injection (DI). Which is turn drives which class to create.
What if you’re working on an older system that doesn’t have the necessary DI framework to get the Strategy Pattern working? What if your data doesn’t have all the necessary information to always make an accurate decision?
I can’t answer these questions for you. You need to make the best decision given the situation you find yourself in. Maybe it’s using the Factory Pattern, maybe Strategy, maybe it’s something else.
Takeaways
At the end of the day Design Patterns are tools in your proverbial tool box. Know your different tools, know how to use them and apply when necessary. The Factory Pattern won’t solve all your problems. But it will probably solve some of them. When you encounter those situations, be glad that the Factory Pattern saved you some programming and design time.
I’m Morgan Kenyon. I’m a .NET developer working in the DFW area. I find C# a great language to use and it’s also backed by a great ecosystem, I love solving hard problems and want to continue talking about the tech I use. If you found this article helpful or thought provoking leave a comment and lets connect over LinkedIn!
