Car Dealer sample - Strategy Pattern

Prev Post

In the last post, we designed move behaviour of car for our famous DOOP car dealer web site. We observed couple of problems with that particular design. To explain the issue in brief, we had added MoveWithV4, MoveWithV6 kind of methods in base class Car, thinking that we do not need to duplicate code in all deriving classes. But the problem we ended up with is making certain cars move with powerful engines though the car does not actually support the engine. Finally, we thought to externalize or separate the varying behaviour out of Car class. The varying behaviour was Moving car with engine. In this post, lets see how Strategy pattern comes to rescue us from the problems explained above.

Strategy Pattern :

Intent from GoF : Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

This means, when you a more than way to implement certain feature or to solve certain problem (call it an algorithm), the client need not be tied to a particular implementation. Client should get flexibility to shift to any other algorithm without being modified. Strategy pattern applies to a design problem where client need to dynamically interchange the algorithms (feature or responsibility implementation) and vary them independently, without being tied to certain way of implementation. UML below describes the strategy pattern.

As you observe, Strategy class defines an interface to access the algorithm. Client is only exposed to Strategy class, and not to the ConcreteStrategy classes which are actual implementations of algorithm. In above notation, client can have reference to more than one concrete implementation, based on the requirement for design. Now you know what is strategy pattern is and what its UML looks like. Lets apply this pattern to our car dealer example's move car behaviour. Take a look at the following UML diagram.

The design shows that we have separated Engine out of Car(no no..we didnt take engine out of the car..we just delegated the move behaviour to engine). Car class has reference to Engine instance and Move method in Car class just calls this.i_Engine.Move. If you observe, we see 2 deriving heirarchies, one for Car and another one for Engine. Car has very deriving subclasses as Corrola, Accord, whereas Engine has V4 and V6. A car instance will be created with a particular Engine. That way, respective engine instance can be passed that particular car instance, such as V4 to Corrola and V6 to Accord. So when you call Car.Move, it calls respective engine's move method. Move behaviour is well encapsulated into Engine class, and its not duplicated. The strategy interface here is Engine class, and V4 and V6 are concrete implementation of strategy class. Dynamically different car types can load different strategy based on their moving behaviour.

Strategy pattern is most widely used pattern. You will find this pattern in various designs and it serves the purpose the best. Other examples of Strategy pattern are listed below.

1. ArrayList.Sort( IComparer ), ArrayList.BinarySearch( IComparer ),
String.Format( IFormatProvider.. )

In all of the above methods, the behaviour of Comparing, formatting is externalized to another class. This provides flexibility to change implementation at runtime dynamically.

2. System.Collections.Generics make heavy use of Strategy.

3. System.Security.Cryptography.

We have seen how to use decorator and strategy patterns in various scenarios. Next we will go over Composite pattern and apply it to car dealer sample. until then..happy patterning..

Next post