1

CSC 413 - Software Development

5. Strategy Design Pattern

2/3/18

John Roberts

2
Overview
• SOLID

• Strategy Design Pattern

3
SOLID

• Acronym for five basic principles of Object Oriented

Programming, named by Robert Martin (Uncle Bob)

• The intention is that these principles, when applied

together, will make it more likely that a programmer will
create a system that is easy to maintain and extend over
time (Wiki)

3
 4
Single Responsibility Principle

• A class (or function, or method) should have only a single

responsibility

• Only one potential change in the software’s specification

should be able to affect the specification of the class

• Wikie: Single Responsibility Principle

5 Interfaces/Abstract classes, inheritance

Open/Closed Principle

• Software entities should be open for extension, but

closed for modification

• Such an entity can allow its behavior to be extended

without modifying its source code - how is this
accomplished in Java?

• This is relevant for the Strategy pattern we are using,

more on this shortly…

• Wiki: Open/Closed Principle

6
Liskov Substitution Principle

• Objects in a program should be replaceable with

instances of their subtypes without altering the
correctness of that program

• Particular definition of a sub typing relation called

strong behavioral sub typing

• This is also relevant for the Strategy design pattern…

• Wiki: Liskov Substitution Principle

6
 7
Interface Segregation Principle

• Many client specific interfaces are better than one general

purpose interface

• Split interfaces that are very large into smaller, more

specific interfaces so that clients will only have to know
about the methods of interest to them

• Such shrunken interface are called role interfaces

• Wiki: Interface Segregation Principle

8 Example reproduced from http://www.oodesign.com/dependency-inversion-

Dependency Inversion Principle principle.html

• Depend on abstractions, not concretions In bad example, can’t easily replace worker with different type of worker

• High level modules should not depend on low level In good example, both high level (Manager) and low level (Worker and
modules - both should depend on abstractions
SuperWorker) depend on abstraction, easy to swap
• Abstractions should not depend on details. Details
should depend on abstractions.

• Github: Lecture 5

• Wiki: Dependency Inversion Principle

9
Overview
• SOLID

• Strategy Design Pattern

9
 10 Much of this taken from wiki and the Gang of 4 book
Strategy Design Pattern

• (AKA the policy pattern)

• Behavioral software design pattern that enables an

algorithm’s behavior to be selected at runtime

• Defines a family of algorithms

• Encapsulates each algorithm

• Makes the algorithm interchangeable within that family

10

11
Open/Closed Principle

• Recall: Software entities should be open for extension,

but closed for modification

• How is this pattern closed for modification?

• How is this pattern open for extension?

11

12
Open/Closed Principle

• Recall: Software entities should be open for extension,

but closed for modification

• How is this pattern closed for modification?

• Through the use of interface or abstract base class

• How is this pattern open for extension?

• Through the creation of concrete types for the abstract

base class

12
 13 Where have we seen this pattern before?
Liskov Substitution Principle

• Recall: Objects in a program should be replaceable with

instances of their subtypes without altering the
correctness of that program

• We can replace references to the abstract base class

with concrete implementations of a given algorithm (a
strategy)

13

14
Operator class

• Abstract base class Operator, with concrete classes to

implement the algorithm for specific Operators

Operator

evaluate( one : Operand, two : Operand )

AdditionOperator MultiplicationOperator

evaluate( … ) evaluate( … ) 14

15
References

• Wiki: Strategy Pattern

• Sourcemaking: Strategy Pattern

15