CSC/ECE 517 Fall 2010/ch3 3h PW: Difference between revisions
Line 154: | Line 154: | ||
==Strategy Pattern Compared to State Pattern== | ==Strategy Pattern Compared to State Pattern== | ||
Another design pattern that is in use is the [http://en.wikipedia.org/wiki/State_pattern state pattern] and it is actually very similar to the strategy pattern. With the state pattern, the object's actions or algorithm still can be changed and it is created in a separate class. The difference is that the state will change over time and as it changes the behavior automatically changes as well. So, with the State pattern the behavior changing is done automatically, and the Strategy pattern requires the client that created the object to assign a new action or behavior. | |||
==References== | ==References== |
Revision as of 22:15, 6 October 2010
The Strategy pattern in static and dynamic languages
What is the Strategy Pattern
The strategy pattern is a type of design pattern. The main purpose of the strategy pattern is to separate out an object and how it behaves so that it can be changed at runtime. The first advantage for doing this is so that if an object can have different behaviors then it is easy to manage them in their own classes. Secondly, if a certain type of behavior need to be changed, it only need to be changed in that behavior class rather than in multiple classes if there were multiple objects that had this behavior.
The following drawing supports the example's below.
Advantages of using the Strategy Pattern
How to Implement in a Static Language
The static languages implement the strategy pattern by creating a class and inside of that class is a reference to an action class. This action class is usually a superclass, that way one of the actual types of actions to be perform can be assigned. These actions are essentially subclasses of the action class. In java, we can use the abstract type interface which means any class that implements it must define each of the abstract functions. In the example below, the main object is the BasketballPlayer class. In that class is a reference to the Action interface. The Action interface has an abstract method perform. There are 3 classes that implement the Action class. They are Pass, Dribble, and Shoot. Each of these methods defines the method perform and then does that action. The BasketballPlayerExample class shows how to instantiate the BasketballPlayer class and then define different actions for it.
Example
Java Code
interface Action { void perform(); } // Implements the algorithm using the strategy interface class Dribble implements Action { public void perform() { System.out.println("Player is dribbling"); } } class Pass implements Action { public void perform() { System.out.println("Player is passing"); } } class Shoot implements Action { public void perform() { System.out.println("Player is shooting"); } } // Configured with a ConcreteStrategy object and maintains a reference to a Strategy object class BasketballPlayer { private Action action; // Constructor public BasketballPlayer(Action action) { this.action = action; } public void perform() { action.perform(); } } //BasketballPlayerExample test application class BasketballPlayerExample { public static void main(String[] args) { BasketballPlayer bballPlayer; // Three contexts following different strategies bballPlayer = new BasketballPlayer(new Dribble()); bballPlayer.perform(); bballPlayer = new BasketballPlayer(new Pass()); bballPlayer.perform(); bballPlayer = new BasketballPlayer(new Shoot()); bballPlayer.perform(); } }
How to Implement in a Dynamic Language
Dynamic languages implement the strategy pattern by extracting out the different behaviors of the main action method into individual classes or modules. In the example below, the main object is the BasketballPlayer class. In the example below, modules are used to encapsulate the three actions. They are Pass, Dribble, and Shoot. Each of these modules defines the method perform and then does that action. The instantiations at the end show how to create the BasketballPlayer objects and use them to perform the actions defined in the modules.
Examples
Ruby code
#Class to be instantiated for use in the Strategy pattern class BasketballPlayer def initialize(&action) @action = action end def perform @move.call end def method_missing(method_name) puts "#{action} is not a known b-ball play" end end #The Strategies - the modules that implement the different behaviors that our object would use module Pass def pass puts"Player is passing!" end end module Dribble def dribble puts "Player is dribbling!" end end module Shoot def shoot puts "Player is shooting!" end end #Lets test the strategy pattern bballPlayer = BasketballPlayer.new(dribble) offense.perform #=>Player is dribbling! bballPlayer = BasketballPlayer.new(pass) defense.perform #=>Player is passing! bballPlayer = BasketballPlayer.new(shoot) offense.perform #=>Player is passing! ...
Ruby Code using Blocks
#Class to be instantiated for use of the Strategy Pattern class BasketballPlayer def initialize(&action) @action = action end def perform @action.call end end #Lets test the strategy pattern #By using blocks of code, classes or modules do not need to be created and the methods do not need to be declared. a = BasketballPlayer.new { puts 'Player is passing!' } a.perform #=> Player is passing! b = BasketballPlayer.new { puts 'Player is dribbling!' } b.execute #=> Player is dribbling! c = BasketballPlayer.new { puts 'Player is shooting!' } c.perform #=> Player is shooting!
Strategy Pattern Compared to State Pattern
Another design pattern that is in use is the state pattern and it is actually very similar to the strategy pattern. With the state pattern, the object's actions or algorithm still can be changed and it is created in a separate class. The difference is that the state will change over time and as it changes the behavior automatically changes as well. So, with the State pattern the behavior changing is done automatically, and the Strategy pattern requires the client that created the object to assign a new action or behavior.
References
[1] Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates; 'Head First Design Patterns', O'Reilly, 2004
[2] Strategy Pattern Wikipedia Entry