Assignment – 1

Design Patterns - Strategy Pattern

An assignment submitted as part of the requirement for evaluation of

System Method II - STY3221

Done By

Preethi Ravi

Course Director

Mr. R. Sathiyavelu

Cambrian College-Achariya Campus

Villianur

11th October, 2010

 Strategy Pattern
Design Pattern
A design Pattern is a template that a software developer can use to solve a real world
application project. Think of it as an empty flow chart diagram with symbols that represent
actions that an application will perform based on certain criteria. The developer can choose
which pattern best suits their needs. There are a variety of design patterns and design
methodologies that have been carefully developed for a wide range of software development
projects.

Strategy Pattern

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

When to use
In applications, this pattern is rarely employed because application designers generally
know the scope of the business rules (i.e. logic) and don't really need the ability to swap in new
or unknown rules after the system has been built. Any changes to those rules will generally be
part of a larger project change and the overhead of switching to newer rules is fairly minimal. I
disagree with this and think the strategy pattern can bring advantages to an application, but that's
traditionally the thinking in application design.

Motivation

There are common situations when classes differ only in their behavior. For this case is a
good idea to isolate the algorithms in separate classes in order to have the ability to select
different algorithms at runtime.

Introduction
  As we all have a brief idea of what design patterns and what role it plays in the Software
Development Life Cycle. Now we will look into one of the most important pattern known as
"Strategy Pattern". Let’s start up with an example.

In this Article we will also use the following design principles:

 Strategy Pattern
 Identify the aspects of your application that vary and separate them from what stays the
same.
 Program to an interface, not an implementation
 Favor Composition over inheritance

Example

Problem (WorldCarSimulator)

A simulator which demonstrates the types of worldwide cars and their features. Users can
choose any type of cars, and then the simulator should give a demonstration of the type of car
selected with the features available for that car.
 Strategy Pattern
Start with the basic design: 

 Here the Car is the base class. Taxi and Rented Car’s are the derived classes.
 Carry () is defined in base class and run () is overridden in the derived classes as required.

Suddenly you recognize that, as this is for worldwide cars, there are some cars, which go
for race. 
 Only change required is to add a race () method in the base class so some cars can go for
the race.
 Update the code with race () method and now the code is ready for demo.
 User starts the Demo, Something went horribly wrong.
"Taxi's started racing"
"Racecar’s started carrying passengers"

Now code needs to be modified.

Modify Taxi Class

 Strategy Pattern
 Race() to do nothing

Modify Racecar Class

 Carry() to do nothing

Consider about ToyCar they do not race nor they do not carry.
 
Create the ToyCar Class

 Race() to do nothing
 Carry() to do nothing

As long as new type of car's come, the more modification is required. Let us think about some
alternative solution like the following below.
 
 Strategy Pattern
 

In the above design, there is no reusability. As long as you add classes you need to override the
methods carry () or race() etc. so this is not a good design.
 
Let us use Design Principle one:

"Identify the aspects of your application that vary and separate them from what stays the same"

Like this:
And one more thing we are using classes where in we do not have a chance for dynamic
behavior. I.e... for example Taxi started taking passengers and after some time it want to go for a
race, which is not possible as per the last design.
 
Ok. Let’s implement the second design principle:
 Strategy Pattern

"Program to an interface, not an implementation"

Let see the design now using the two principles:

 

 
We just had designed for the behavior of Car's like Carry, Race etc.. Now we need to design the
Types of Cars. It's now time to use the third principle.
"Favor Composition over inheritance"
 Strategy Pattern
Here is the final design:
 

Strategy Pattern Explained:

 

  
Participants 
 
The classes and/or objects participating in this pattern are:
 Strategy Pattern
 Strategy (Sort Strategy)
o Declares an interface common to all supported algorithms. Context uses this
interface to call the algorithm defined by a Concrete Strategy 
 Concrete Strategy (Quick Sort, Shell Sort, Merge Sort)
o implements the algorithm using the Strategy interface

 Context (Sorted List) 

o is configured with a Concrete Strategy object
o maintains a reference to a Strategy object 
o May define an interface that lets Strategy access its data.

 Observer (IInvestor)
o Defines an updating interface for objects that should be notified of changes in a
subject. 
 Concrete Observer (Investor)
o maintains a reference to a Concrete Subject object
o stores state that should stay consistent with the subject's
o implements the Observer updating interface to keep its state consistent with the
subject's

Conclusion:

The strategy pattern allows for a family of interchangeable algorithms. These algorithms can be
interchanged freely with no effect on the design; the correct behavior is delegated to the actual
object. As demonstrated in this article all behavior that varies, e.g. the engines have been isolated
from that which doesn’t vary. Each engine is programmed to an interface not an implementation,
although you could use an abstract class.

The beauty of the strategy pattern is its simplicity. We have a robust and maintainable design
that can be further extended in the future, yet the design is incredibly simple.