Strategy

It’s a Behavioral Pattern, allowing to define algorithms and place them in different classes, and make their objects convertible. 

Problems to solve by Strategy Pattern

Imagine hypothetically a situation (which could but not had to had it’s place in real life), that you with friends have drunk God’s ambrosia all night long and woke up early in the morning at 6 A.M. Your head is throbbing due to hangover, and the worst is yet to come – you’ve got lectures at 7 A.M. with the worst professor at the University. Unfortunately you can’t get another sick leave, because if you won’t attend in atleast 50% of lectures – you’re not allowed to proceed to the exam. So – there is a must to participate in this lecture – to the University there is about 40 mins by feet, which you know inside out, but the hangover gets bigger and bigger, so there is a possibility that you wouldn’t make it at time.  Life’s dependency states clear: if something works perfectly in one case, there is a chance that it will (not) work in other case.  Fortunate for you, there is a hope – getting picked up by TAXI. The TAXI driver doesn’t know the route, so you’re leading taxi driver step by step as you would’ve taken by feet. Unluckily you didn’t predict, that this route is not intended for cars and in the end you had to take another way to the University, which eventually resulted in being late.

Translating to programming language: we have a first version of our application, which could plan routes by feet. Unfortunately, sometimes there is an urgent need to move somewhere by bike. So, the next version of application has been updated with chance to move to destination by bike. In the end, the time has come for automobile’s route. We made it, but our code got more messy with any time the other optional movement has been implemented. Every change of any algorithm – bug’s removal / route’s improvements has its influence on whole class. 

Strategy Solution

This Pattern proposes an extraction of algorithms which are responsible for given task, and placing them in separated classes called strategies.

Base class is called as context, and its goal is to create a route from start, to end. To do that we can create an interface, which could implement the same method as the context. Our base class will aggregate this interface to delegate an implementation to other classes. 

 public interface IRouteStrategy
{
        void CreateRoute(Coordinate start, Coordinate end);

} 

public class Map
{
        private IRouteStrategy _routeStrategy;

        public Map(IRouteStrategy routeStrategy)
        {
            _routeStrategy = routeStrategy;
        }
        public void CreateRoute(Coordinate start, Coordinate end)
        {
            _routeStrategy.CreateRoute(start, end);
        }
}

 public class Coordinate
{

        public double Longtitude { get; set; }
        public int Latitude { get; set; }

}

 public class StrategyWalk: IRouteStrategy
{
        public void CreateRoute(Coordinate start, Coordinate end)
        {
            Console.WriteLine("Walk strategy");
        }
}

 public class StrategyBike: IRouteStrategy
{

        public void CreateRoute(Coordinate start, Coordinate end)
        {
            Console.WriteLine("Bike strategy");
        }

}

 public class StrategyCar: IRouteStrategy
{
        public void CreateRoute(Coordinate start, Coordinate end)
        {
            Console.WriteLine("Car strategy");
        }

}

In our navigation app, every single algorithm can be extracted to its own separated class implemented with one CreateRoute method, which takes information about starting and ending point, and in the end returns stages of created route. Of course, every class designating specific route, has a possibility to designate another route, based on the same arguments, where base class Map does not have to know exactly about given algorithm, because it only displays it.