CS 350 – Software Design The Strategy Pattern – Chapter 9 Changes to software, like other things in life, often focus on the immediate concerns and ignore the longer term. Two common approaches: Overanalyze and overdesign: Analysis paralysis Overanalyze and overdesign: Analysis paralysis Jump right in Jump right in Somewhere in between is the ideal. This is why I feel the argument in Software Engineering about Agile methodologies vs. traditional waterfall development is silly. It should always be a combination. In addition, a key element is to be wise enough to DESIGN FOR CHANGE. Simple to say, no so intuitive (at first) to do. With practice, it’s not that difficult.

CS 350 – Software Design The Strategy Pattern – Chapter 9 We do not anticipate the exact change, instead we anticipate what may change. New Case Study: E-Commerce System The company is located in the US, but its business has an international scope A Task controller object handles sales request and passes it to the SalesOrder object to process the order.

CS 350 – Software Design The Strategy Pattern – Chapter 9 The functions for SalesOrder include the following: Allow for filling out the order with a GUI Allow for filling out the order with a GUI Handle tax calculations Handle tax calculations Process the order and print a sales receipt Process the order and print a sales receipt Some object will be implemented with the help of other objects SalesOrder will not print itself SalesOrder will not print itself

CS 350 – Software Design The Strategy Pattern – Chapter 9 What happens when requirements change? Perhaps a new requirement for taxation rules is added. Handle taxation for countries outside the United States. Thus, we need to add new rules for computing taxes.

CS 350 – Software Design The Strategy Pattern – Chapter 9 How do we handle different implementations of tasks that are pretty much conceptually the same? Copy and paste Copy and paste Switches/Ifs on variable specifying the case we have Switches/Ifs on variable specifying the case we have Use function pointers (a different one representing each case) Use function pointers (a different one representing each case) Inheritance Inheritance Delegate the entire functionality to a new object Delegate the entire functionality to a new object

CS 350 – Software Design The Strategy Pattern – Chapter 9 Copy / Paste Traditional method Traditional method Copy something that works, paste it somewhere else, make a changes. Copy something that works, paste it somewhere else, make a changes. Maintenance headaches Maintenance headachesSwitches Issues with coupling, testing Issues with coupling, testing More importantly, what happens when you have multiple variations? More importantly, what happens when you have multiple variations?

CS 350 – Software Design The Strategy Pattern – Chapter 9 Simple Cases – Two Countries // Handle Tax switch (myNation) { case US: case US: //US Tax Rules here //US Tax Rules here break; break; case Canada: case Canada: //Canadian Tax Rules here //Canadian Tax Rules here break; break;} //Handle Currency switch (myNation) { case US: case US: //US Currency Rules here //US Currency Rules here break; break; case Canada: case Canada: //Canadian Currency Rules here //Canadian Currency Rules here break; break;} //Handle Date Format switch (myNation) { case US: case US: //US Date Format Rules here //US Date Format Rules here break; break; case Canada: case Canada: //Canadian Date Format Rules here //Canadian Date Format Rules here break; break;}

CS 350 – Software Design The Strategy Pattern – Chapter 9 Add a Third Country – Still a “Clean” implementation // Handle Tax switch (myNation) { case US: case US: //US Tax Rules here //US Tax Rules here break; break; case Canada: case Canada: //Canadian Tax Rules here //Canadian Tax Rules here break; break; case Germany: case Germany: //Germany Tax Rules here //Germany Tax Rules here break; break;} //Handle Currency switch (myNation) { case US: case US: //US Currency Rules here //US Currency Rules here break; break; case Canada: case Canada: //Canadian Currency Rules here //Canadian Currency Rules here break; break; case Germany: case Germany: //Germany Currency Rules here //Germany Currency Rules here break; break;}

CS 350 – Software Design The Strategy Pattern – Chapter 9 Add a Third Country – Still a “Clean” implementation You may need to add another switch // Handle Language switch (myNation) { case US: case US: case Canada: case Canada: //use English //use English break; break; case Germany: case Germany: //use German //use German break; break;}

CS 350 – Software Design The Strategy Pattern – Chapter 9 Variations “dirty” the implementation // Handle Language switch (myNation) { case Canada: case Canada: if (inQuebec) { if (inQuebec) { //use French //use French break;} break;} else else //use English //use English break; break; case Germany: case Germany: //use German //use German break; break;} Flow of the switches is hard to read When new cases come in, you must find every place it can be involved Called Switch Creep

CS 350 – Software Design The Strategy Pattern – Chapter 9 Function Pointers Nice Nice Compact Compact Can’t retain state on a per-object basis Can’t retain state on a per-object basisInheritance Nothing really wrong with it per say Nothing really wrong with it per say Certainly allows reuse Certainly allows reuse Could create new SalesOrder objects from existing objects Could create new SalesOrder objects from existing objects

CS 350 – Software Design The Strategy Pattern – Chapter 9 Inheritance What happens when things vary independently? Too many classes! Thing of the German example where we may vary data format, language, and freight rules

CS 350 – Software Design The Strategy Pattern – Chapter 9 A Better Approach 1. Find out what varies and encapsulate it in a class of its own. 2. Contain this class in another class. What varies in this example? Tax rules, therefore create an abstract class that defines how to accomplish taxation conceptually.

CS 350 – Software Design The Strategy Pattern – Chapter 9 A Better Approach Now use aggregation to give the SalesOrder object the ability to handle Tax.

CS 350 – Software Design The Strategy Pattern – Chapter 9 public abstract class CalcTax { abstract public double taxAmount(long itemSold, double price); } abstract public double taxAmount(long itemSold, double price); } Public class CanTax extends CalcTax { public double TaxAmount (long itemSold, double price){ public double TaxAmount (long itemSold, double price){ //in real life, figure out tax according to the rules in Canada and return it //in real life, figure out tax according to the rules in Canada and return it //here return 0 so this will compile //here return 0 so this will compile return 0.0; return 0.0; }} Public class USTax extends CalcTax { public double TaxAmount (long itemSold, double price){ public double TaxAmount (long itemSold, double price){ //in real life, figure out tax according to the rules in the US and return it //in real life, figure out tax according to the rules in the US and return it //here return 0 so this will compile //here return 0 so this will compile return 0.0; return 0.0; }}

CS 350 – Software Design The Strategy Pattern – Chapter 9 public class SalesOrder { public void process (CalcTax taxToUse) { public void process (CalcTax taxToUse) { long itemNumber=0; long itemNumber=0; double price=0; double price=0; //given the tax object to use, calculate the tax //given the tax object to use, calculate the tax double tax = taxToUse.taxAmount(itemNumber, price); double tax = taxToUse.taxAmount(itemNumber, price); }} public class TaskController { public void process() { public void process() { // this code is an emulation of a processing task controller // this code is an emulation of a processing task controller // figure out what country you are in // figure out what country you are in CalcTax myTax; CalcTax myTax; myTax = getTaxRulesForCountry(); myTax = getTaxRulesForCountry(); SalesOrder mySO = new SalesOrder(); SalesOrder mySO = new SalesOrder(); mySO.process(myTax); mySO.process(myTax);}

CS 350 – Software Design The Strategy Pattern – Chapter 9 A Better Approach

CS 350 – Software Design The Strategy Pattern – Chapter 9 So What’s the Difference? Looking at it quickly, it appears we just pushed the problem down the chain. The key difference is that in the original solution, there was one large hierarchy containing all the variation. The improved solution has a few, smaller, independent hierarchies. Also other pieces of the system can use the smaller object hierarchies we created.

CS 350 – Software Design The Strategy Pattern – Chapter 9 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. The Strategy Pattern is based on a few principles: Objects have responsibilities Objects have responsibilities Different specific implementations of these responsibilities are manifested through the use of polymorphism Different specific implementations of these responsibilities are manifested through the use of polymorphism There is a need to manage several different implementations of the same basic algorithm. There is a need to manage several different implementations of the same basic algorithm. It is good design practice to separate behaviors that occur in the same problem domain from each other.

CS 350 – Software Design The Strategy Pattern – Chapter 9 Strategy Pattern Intent: Enable you to use different business rules or algorithms depending on the context in which they occur. Problem: The selection of an algorithm that needs to be applied depends on the client making the request or the data being acted on. Solution: Separate the selection of the algorithm from the implementation of the algorithm.

CS 350 – Software Design The Strategy Pattern – Chapter 9 Strategy Pattern Implementation: Have the class that uses the algorithm (Context) contain an abstract class (Strategy) that has an abstract method specifying how to call the algorithm. Each derived class implements the algorithm needed.