Design Patterns for Extensibility : Strategy Pattern

strategy-640x303

Technology is rapidly changing, thus the requirements are also changing expeditiously when it comes to software development. Adopting changes to the already written code is not an easy task. With the arrival of cloud and since there are so many options for the developers, the software needs to be expanded to fit the customer need with great efficiency. Re-compilation and re-deployment does occur time to time with shorter interval, but on the other hand to reduce the errors, teams and engineers does not like to alternate the code base for each and every change.

software_cola_mentos

This is the situation where developers and software architects begin to work on extensibility of the software architecture – which just ease the task of software developers and the software support engineers in a passive manner. There will be some added functionalities and features when the software is extended. To expand properly, the expansion has to be taken into the consideration at the very early stages of the software development.

In this blog post, lets have a look at one software design pattern that make sure the extensibility of the software is being kept – it is “Strategy Pattern“.

Strategy Pattern is a behavioral software design pattern, which enables choosing of an algorithm at the runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.

A strategy interface would be implemented by many concrete strategies and they are not interconnected. If a new class is added, the newly added class can access other classes by using its objects. Adding a new class doesn’t make any changes to the existing functionalists and this pattern is suitable for introducing new features to perform one task in the future.

stategy-class-diagram1


public class Context
{
    private IStrategy _strategy;

    public void SetStategy(IStrategy strategy)
    {
        this._strategy = strategy;
    }

    public void DoOperation()
    {
        _strategy.DoBehaviour();
    }
}

public interface IStrategy
{
    void DoBehaviour();
}

public class ConcreteStrategyA : IStrategy
{
    public void DoBehaviour()
    {
        // Code goes here
    }
}
public class ConcreteStrategyB : IStrategy
{
    public void DoBehaviour()
    {
        // Code goes here
    }
}
public class ConcreteStrategyC : IStrategy
{
    public void DoBehaviour()
    {
        // Code goes here
    }
}

And in the client application,


    public class Client
    {
        public void Operate()
        {
            Context context = new Context();
            context.SetStategy(new ConcreteStrategyA());
            context.DoOperation();
        }
    }

So, whenever a new feature is required, we just create a new ConcreteStrategy implementing the IStrategy and write the logic for it.

This design pattern ensures the existing classes are closed for modification and open for extension by having separate interfaces and encapsulating classes, and since the classes are more robust, this satisfies  “Single Responsibility Principle” and “Open-Closed Principle“.

Real-world Example.

Messaging – in the early days of computing, email was the only way to deliver messages but now we have SMS, IMs, Push notifications ect. But who knows what will come in the future. This could be a real-world use case for implementing strategy pattern. Due to the pluggable nature this pattern could be mostly used in “system to system” integrations as well.

One thought on “Design Patterns for Extensibility : Strategy Pattern

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s