350 CS 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 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, its 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 Handle tax calculations Process the order and print a sales receipt Some object will be implemented with the help of other objects 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 Switches/Ifs on variable specifying the case we have Use function pointers (a different one representing each case) Inheritance Delegate the entire functionality to a new object
CS 350 Software Design The Strategy Pattern Chapter 9
Copy / Paste
Traditional method Copy something that works, paste it somewhere else, make a changes. Maintenance headaches
Switches
Issues with coupling, testing 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) { (myNation) case US: //US Tax Rules here break; case Canada: //Canadian Tax Rules here break; } //Handle Currency switch (myNation) { (myNation) case US: //US Currency Rules here break; case Canada: //Canadian Currency Rules here break; } //Handle Date Format switch (myNation) { (myNation) case US: //US Date Format Rules here break; case Canada: //Canadian Date Format Rules here break; }
CS 350 Software Design The Strategy Pattern Chapter 9
Add a Third Country Still a Clean implementation
// Handle Tax switch (myNation) { (myNation) case US: //US Tax Rules here break; case Canada: //Canadian Tax Rules here break; case Germany: //Germany Tax Rules here break; } //Handle Currency switch (myNation) { (myNation) case US: //US Currency Rules here break; case Canada: //Canadian Currency Rules here break; case Germany: //Germany Currency Rules here 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) { (myNation) case US: case Canada: //use English break; case Germany: //use German break; }
CS 350 Software Design The Strategy Pattern Chapter 9
Variations dirty the implementation
// Handle Language switch (myNation) { (myNation) case Canada: if (inQuebec) { (inQuebec) //use French break;} else //use English break; case Germany: //use German 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 Compact Cant retain state on a per-object Inheritance basis Nothing really wrong with it per say Certainly allows reuse 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); } itemSold, Public class CanTax extends CalcTax { public double TaxAmount (long itemSold, double price){ itemSold, //in real life, figure out tax according to the rules in Canada and return it Canada //here return 0 so this will compile return 0.0; } } Public class USTax extends CalcTax { public double TaxAmount (long itemSold, double price){ itemSold, //in real life, figure out tax according to the rules in the US and return it the //here return 0 so this will compile return 0.0; } }
CS 350 Software Design The Strategy Pattern Chapter 9
public class SalesOrder { public void process (CalcTax taxToUse) { (CalcTax taxToUse) long itemNumber=0; itemNumber=0; double price=0; //given the tax object to use, calculate the tax double tax = taxToUse.taxAmount(itemNumber, price); taxToUse.taxAmount(itemNumber, } } public class TaskController { public void process() { // this code is an emulation of a processing task controller controller // figure out what country you are in CalcTax myTax; myTax; myTax = getTaxRulesForCountry(); getTaxRulesForCountry(); SalesOrder mySO = new SalesOrder(); 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 Whats the Difference? Looking at it quickly, it appears we just pushed the problem down the chain. The...