CS 350 Software Design The Strategy Pattern Chapter 9

1
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
• 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.

2
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.

3
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

4
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.

5
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

6
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?

7
CS 350 Software Design The Strategy Pattern
Chapter 9

• Simple Cases Two Countries
• // Handle Tax
• switch (myNation)
• case US
• //US Tax Rules here
• break
• case Canada
• //Canadian Tax Rules here
• break
• //Handle Currency
• switch (myNation)
• case US
• //US Currency Rules here
• break
• case Canada
• //Canadian Currency Rules here

8
CS 350 Software Design The Strategy Pattern
Chapter 9

• Add a Third Country Still a Clean
  implementation
• // Handle Tax
• switch (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)
• case US
• //US Currency Rules here

9
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 Canada
• //use English
• break
• case Germany
• //use German
• break

10
CS 350 Software Design The Strategy Pattern
Chapter 9

• Variations dirty the implementation
• // Handle Language
• switch (myNation)
• case Canada
• if (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

11
CS 350 Software Design The Strategy Pattern
Chapter 9

• Function Pointers
• Nice
• Compact
• Cant retain state on a per-object basis
• Inheritance
• Nothing really wrong with it per say
• Certainly allows reuse
• Could create new SalesOrder objects from
  existing objects

12
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

13
CS 350 Software Design The Strategy Pattern
Chapter 9

• A Better Approach
• Find out what varies and encapsulate it in a
  class of its own.
• 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.

14
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.

15
CS 350 Software Design The Strategy Pattern
Chapter 9

• public abstract class CalcTax
• abstract public double taxAmount(long
  itemSold, double price)
• Public class CanTax extends CalcTax
• public double TaxAmount (long itemSold, double
  price)
• //in real life, figure out tax according to
  the rules in Canada and return it
• //here return 0 so this will compile
• return 0.0
• Public class USTax extends CalcTax
• public double TaxAmount (long itemSold, double
  price)
• //in real life, figure out tax according to
  the rules in the US and return it
• //here return 0 so this will compile
• return 0.0

16
CS 350 Software Design The Strategy Pattern
Chapter 9

• public class SalesOrder
• public void process (CalcTax taxToUse)
• long itemNumber0
• double price0
• //given the tax object to use, calculate
  the tax
• double tax taxToUse.taxAmount(itemNumber,
  price)
• public class TaskController
• public void process()
• // this code is an emulation of a
  processing task controller
• // figure out what country you are in
• CalcTax myTax
• myTax getTaxRulesForCountry()
• SalesOrder mySO new SalesOrder()
• mySO.process(myTax)

17
CS 350 Software Design The Strategy Pattern
Chapter 9

• A Better Approach

18
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 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.

19
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
• 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.
• It is good design practice to separate behaviors
  that occur in the same problem domain from each
  other.

20
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.

21
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.