C# Design Patterns: The Strategy Pattern
Stop me if you’ve heard this before, but you should learn Design Patterns.
As a software engineering I’m constantly solving problems. But more than likely most of the problems you’re encountering aren’t new problems.
They’re problems that lots of software engineers have faced before. Because these problems are so frequent in nature, over time the software development community has come to agreement on the best way to solve particular problems.
These standard problems and solutions are called Design Patterns. Design Patterns are helpful in two common ways. First, Design Patterns help guide software engineers in solutions to the problems they face. Second, they give developers a common vocabularly to talk solutions to common problems.
In this article I’m going to introduce and talk about the Strategy Pattern. It’s a common design pattern that helps your program maintain flexibility in the midst of diverse requirements.
OrderSummary
Lets say that you’re a developer working on an app that sends an OrderSummary to a downstream system whenever a purchase is made.
We have an object that contains UserId, ItemId and PurchaseDate. Simple but effective. This application is a bit old so your downstream system communicates using xml, so a simple ApiClient might look like the following.
Nothing ground breaking here. Just a simple class that serializes the object and Posts it to the uri.
New Requirements
Wonderful news! Your company is growing! Requirements have changed! Now we need to support an ApiClient that accepts messages in json.
There are a couple different options you could choose:
1. Create an XMLApiClient and JsonApiClient
2. Create a SendOrderSummaryXml and SendOrderSummaryJson method
3. Use the Strategy Pattern to abstract out the generation of the content.
Because this is an article on the Strategy Pattern, lets choose option #3.
We create a new interface to define the contract for building the http content.
Then we create two new concrete classes to implement this new interface, one for XML and one for JSON.
Then update our ApiClient to use that interface to generate the HttpContent for the message.
You see our SendOrderSummary method slimmed down quite a bit. It offloads the responsibility to generate XML or JSON content. Now our ApiClient isn’t even aware of what content type it’s sending.
Great job! Your boss is going to love the fact that you used Design Patterns to improve your applications reusability.
Takeaways and Further Thoughts
The Strategy Pattern is a useful Design Pattern to decouple systems. Our ApiClient can now support any new content types without modifications. Just implement the IOrderSummaryBuilder interface with whatever content type you need and you’re good to go.
One further enhancement is to apply the Strategy Pattern again to parse the response body to a C# class. Create an interface called “IOrderSummaryResponseBuilder”, with an Xml and Json version.
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!
