Scribd
Upload
37 views

CSC 413 - Software Development 5. Strategy Design Pattern: 2/3/18 John Roberts

This document discusses the Strategy design pattern and the SOLID principles of object-oriented programming. The Strategy pattern allows an algorithm's behavior to be selected at runtime by defining a family of algorithms, encapsulating each one, and making them interchangeable. It is closed for modification but open for extension through the use of interfaces/abstract classes and concrete subclasses. The pattern follows the Liskov Substitution and Open/Closed principles by allowing algorithms to be replaced without affecting correctness or requiring modification.

Uploaded by

eveswan2008
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
37 views

CSC 413 - Software Development 5. Strategy Design Pattern: 2/3/18 John Roberts

This document discusses the Strategy design pattern and the SOLID principles of object-oriented programming. The Strategy pattern allows an algorithm's behavior to be selected at runtime by defining a family of algorithms, encapsulating each one, and making them interchangeable. It is closed for modification but open for extension through the use of interfaces/abstract classes and concrete subclasses. The pattern follows the Liskov Substitution and Open/Closed principles by allowing algorithms to be replaced without affecting correctness or requiring modification.

Uploaded by

eveswan2008
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

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

You might also like