Scribd
Upload
93 views19 pages

Software Design Patterns Guide

The document discusses the strategy design pattern, which defines a family of algorithms, encapsulates each one, and makes them interchangeable. It is a behavioral design pattern that allows selecting an algorithm at runtime. Strategy can be used instead of subclassing to avoid complex inheritance structures and allow varying the algorithm dynamically. The key benefits are eliminating conditional statements, providing choice of implementations, and handling families of related algorithms. Potential drawbacks include increased communication overhead and number of objects.

Uploaded by

TranHoaiThuong
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
93 views19 pages

Software Design Patterns Guide

The document discusses the strategy design pattern, which defines a family of algorithms, encapsulates each one, and makes them interchangeable. It is a behavioral design pattern that allows selecting an algorithm at runtime. Strategy can be used instead of subclassing to avoid complex inheritance structures and allow varying the algorithm dynamically. The key benefits are eliminating conditional statements, providing choice of implementations, and handling families of related algorithms. Potential drawbacks include increased communication overhead and number of objects.

Uploaded by

TranHoaiThuong
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Strategy:

A Behavioral Design Pattern

By Anne Ryan
What is a Design Pattern?

A design pattern deals with interactions


between individual software components

They are recurring solutions to common


problems of design!
Types of Design Patterns
Creational
Structural
Behavorial
Strategy is a behavioral design pattern
Strategy
In a Strategy design pattern, you will:

Define a family of algorithms

Encapsulate each one

Make them interchangeable


You should use Strategy when:
You have code with a lot of algorithms
You want to use these algorithms at
different times
You have algorithm(s) that use data the
client should not know about
Strategy Class Diagram

Context Strategy
contextInterface() algorithmInterface()

ConcreteStrategyA ConcreteStrategyB ConcreteStrategyC


algorithmInterface() algorithmInterface() algorithmInterface()
Strategy vs. Subclassing
Strategy can be used in place of
subclassing

Strategy is more dynamic

Multiple strategies can be mixed in any


combination where subclassing would be
difficult
Subclassing

Class
functionX()

SubClass1 SubClass2 SubClass3


functionX() functionX() functionX()
Add a function

Class Add functionY()


functionX()
functionY()

SubClass1 SubClass2 SubClass3


functionX() functionX() functionX()
What happens?
Class
functionX()
Need SIX classes to
functionY() handle both functions!!!

SubClass1 SubClass2 SubClass3


functionX() functionX() functionrX()
functionY() functionY() functionY()

SubClass2.1 SubClass2.2
behaviorY() behaviorY()
Strategy makes this easy!

StrategyX
functionX()

Class
functionX()
functionY()
...
StrategyY
functionY()

...
Benefits of Strategy
Eliminates conditional statements
Can be more efficient than case statements

Choice of implementation
Client can choose among different
implementations with different space and time
trade-offs
Benefits of Strategy
Families of related algorithms
Alternative to subclassing
This lets you vary the algorithm dynamically,
which makes it easier to change and extend
You also avoid complex inheritance structures
Drawbacks of Strategy
Clients must be aware of different
strategies
Clients must know how strategies differ so it
can select the appropriate one
Communication overhead between strategy
and context
Sometimes the context will create and
initialize parameters that are never used
Drawbacks of Strategy
Increased number of objects
if the algorithm differences are simple, the
extra classes add extra complexity
Implementation Issues

Context Strategy
contextInterface() algorithmInterface()

ConcreteStrategyA ConcreteStrategyB ConcreteStrategyC


algorithmInterface() algorithmInterface() algorithmInterface()
Implementation Issues
Concrete Strategy needs efficient access to
data

Should you use a template?

Should you make strategy objects


optional?
Thank you to

Provider of the PowerPoint graphs:


http://vik.ktu.lt/moduliai/
What have we learned today
about strategy?

You might also like