Practical Introduction to Strategy Design Pattern Using Java
By: Parthipan Natkunam
Tags: Java, Clean Code, Design Patterns, Programming, Solid Principles

Class Diagram

What is Strategy Design Pattern?

Strategy design pattern is a behavioural design pattern. It is a tried and tested way of code design that can be used in scenarios where we need to pick up a specific approach (algorithm) from a pool of available related approaches during runtime to achieve something.

This design pattern is also sometimes referred to as the policy pattern.

In this article, let’s look at a practical scenario to utilize this design pattern and let’s write some code in Java to get a hands-on exposure.

The Scenario:

Let’s assume that we have our fictional application that contains some awesome articles and their corresponding URLs (think of Hackernews, maybe?).

you have built this app for the sole purpose of sharing cool articles. now, a rather fascinating idea dawns upon you while you are in the loo. What if you had a feature where your users could share these article links with their connections on various social media? after all, every application and its mother have this feature these days.

After reading through a couple of API documents of different social media apps, you quickly understand that not all social media share API are created equally. sigh :(

so now we are at the point where we have a variety of methods to share the content and we have to choose one depending on the social media app selected by the user (at runtime, in essence). Somehow this sounds familiar to you because this a textbook situation to use a strategy pattern, by definition.

The Approach:

The first step in architecting code following a strategy design pattern is to declare the policy or the strategy (algorithm family). In our case, it would be the steps we would need to share links.

What better way to create a contract or a policy than to use an interface? so, we jump on the keyboard and design the SocialActions interface as follows:

The Interface / Policy:

The Adapters:

Now that we have the family defined (which is “Share”), we need to create a pool of algorithms.

In our case, the sharing algorithm varies depending on the platform on which it is to be shared. So we abstract out the implementation of the sharing algorithm for each platform into its own corresponding adapter classes. By this way, our application at any time has to deal with only a single share method with a pre-defined signature.

For the sake of simplicity and to stay on the point of demonstrating the design pattern, let’s just do only console logs in these variants of the share algorithms instead of actually implementing the sharing mechanisms.

The Context Class:

Now we have four different sharing algorithms to choose from and it is time we created a way to simplify the selection process at runtime for our app by creating a layer of abstraction and expose a consistent and predictable method to share URLs.

This not only makes our code cleaner but also makes the maintenance process less of a nightmare.

The usage:

Finally, let’s look at an example usage of the code we have crafted so far:

The output of the sample driver code above will be as follows: