The Strategy Design Pattern
T
h
e
S
t
r
a
t
e
g
y
P
a
t
t
e
r
n
SE-2811
Dr. Mark L. Hornick
1
C
l
a
s
s
1
-
2
R
e
v
i
e
w
What problems
are we trying to
avoid?
What do we want
to achieve?
SE-2811
Dr. Mark L. Hornick
2
A
d
i
f
f
e
r
e
n
t
a
p
p
r
o
a
c
h
:
I
s
o
l
a
t
e
b
e
h
a
v
i
o
r
s
t
h
a
t
v
a
r
y
,
a
n
d
e
n
c
a
p
s
u
l
a
t
e
t
h
e
m
a
s
a
t
t
r
i
b
u
t
e
s
t
o
e
l
i
m
i
n
a
t
e
i
m
p
l
e
m
e
n
t
a
t
i
o
n
i
n
h
e
r
i
t
a
n
c
e
a
n
d
c
l
a
s
s
e
x
p
l
o
s
i
o
n
s
:
SE-2811
Dr. Mark L. Hornick
3
SimUDuck v5
S
o
r
t
i
n
g
E
x
a
m
p
l
e
Suppose we have a program that sorts Class
objects
Perhaps alphabetically, perhaps by “closeness of
fit”
Perhaps using Bubble Sort, or a (much better)
algorithm like Merge Sort.
SE-2811
Dr. Mark L. Hornick
4
C
o
n
s
i
d
e
r
C
o
l
l
e
c
t
i
o
n
s
.
s
o
r
t
(
)
Collections.sort() implements an
argument which is a
reference to a
concrete class
that implements the
Comparator
interface
, and thus
the behavior of the compare()
method.
Depending on the strategy of the
compare() method in the concrete
class, different sorting will be used
by Collections.sort().
The comparison strategy is
decoupled
from the
Collections.sort() method itself.
SE-2811
Dr. Mark L. Hornick
5
A
n
o
t
h
e
r
s
o
r
t
i
n
g
e
x
a
m
p
l
e
Different strategies for sorting
MergeSort O(NlogN)
QuickSort O(NlogN)
ShellSort In-place,
Ω(
N
(log
N
/log log
N
)
2
)
InsertionSort O(N
2
)
BubbleSort
O(N
2
)
Cool sorting algorithms of the future (or past) …
Would be nice to “plug in” new strategies
SE-2811
Dr. Josiah Yoder
Idea: http://fuchangmiao.blogspot.com/2007/10/strategy-vs-observer.html
6
T
h
e
S
t
r
a
t
e
g
y
D
e
s
i
g
n
P
a
t
t
e
r
n
i
n
i
t
s
g
e
n
e
r
a
l
f
o
r
m
:
C
o
n
c
r
e
t
e
S
t
r
a
t
e
g
y
c
l
a
s
s
e
s
i
m
p
l
e
m
e
n
t
s
p
e
c
i
f
i
c
b
e
h
a
v
i
o
r
s
T
h
e
C
o
n
t
e
x
t
i
s
t
h
e
c
l
a
s
s
t
h
a
t
e
n
c
a
p
s
u
l
a
t
e
s
a
n
d
u
s
e
s
a
s
p
e
c
i
f
i
c
b
e
h
a
v
i
o
r
,
o
r
S
t
r
a
t
e
g
y
.
A
S
t
r
a
t
e
g
y
i
s
a
n
i
n
t
e
r
f
a
c
e
t
h
a
t
d
e
f
i
n
e
s
a
b
e
h
a
v
i
o
r
A
p
p
l
y
i
n
g
t
h
e
S
t
r
a
t
e
g
y
P
a
t
t
e
r
n
:
E
v
i
d
e
n
c
e
1
T
h
e
S
t
r
a
t
e
g
y
P
a
t
t
e
r
n
i
s
a
b
e
h
a
v
i
o
r
a
l
p
a
t
t
e
r
n
u
s
u
a
l
l
y
c
o
n
s
i
d
e
r
e
d
a
n
d
a
p
p
l
i
e
d
a
t
d
e
s
i
g
n
-
t
i
m
e
.
Premise: Your application
requires similar objects
whose behavior varies.
SE-2811
Dr. Mark L. Hornick
8
A
p
p
l
y
i
n
g
t
h
e
S
t
r
a
t
e
g
y
P
a
t
t
e
r
n
:
E
v
i
d
e
n
c
e
2
As a designer, you watch
for inheritance patterns
that result in excessive
behavior overrides
and/or
code duplication
among
classes.
SE-2811
Dr. Mark L. Hornick
9
A
p
p
l
y
i
n
g
t
h
e
S
t
r
a
t
e
g
y
P
a
t
t
e
r
n
:
A
c
t
i
o
n
!
Leave behavior that is
truly
shared
in abstract classes.
Isolate behavior(s) that vary
and declare
interfaces
that
define those behaviors
Implement the
behaviors
in
separate
concrete classes
whose references can be
passed to the Duck ctor
SE-2811
Dr. Mark L. Hornick
10
C
r
e
a
t
i
n
g
D
u
c
k
s
w
i
t
h
s
p
e
c
i
f
i
c
b
e
h
a
v
i
o
r
s
// create some behaviors
SwimBehavior csb = new CircularSwimming();
QuackBehavior sqb = new StandardQuacking();
SwimBehavior rsb = new RandomFloating();
// daffy has circular swimming, std quacking
Waterfowl daffy = new Duck(“daffy”, csb, sqb);
// donald has random floating, std quacking
Waterfowl donald = new Duck(“donald”, rsb, sqb);
daffy.swim();
donald.quack();
SE-2811
Dr. Mark L. Hornick
11
I
n
s
i
d
e
a
D
u
c
k
c
l
a
s
s
// constructor
public void Duck(String name, SwimBehavior sb,
QuackBehavior qb) {super(name, sb, qb)
}
SE-2811
Dr. Mark L. Hornick
12
I
n
s
i
d
e
a
W
a
t
e
r
f
o
w
l
c
l
a
s
s
public abstract class Waterfowl {private SwimBehavior swimBehavior;
private QuackBehavior quackBehavior;
private String name;
// constructor
public void Waterfowl(String name, SwimBehavior sb,
QuackBehavior qb) {this.name = name;
swimBehavior = sb;
quackBehavior = qb;
}
// centralize implementation of behaviors in top-level classes
// if possible; avoid duplication of behavior in subclasses.
// Note we can make this method final to prevent subclasses
from overriding it!
public void swim() {swimBehavior.swim(); // invoke the specific behavior
}
...
SE-2811
Dr. Mark L. Hornick
13
S
t
r
a
t
e
g
y
i
s
a
B
e
h
a
v
i
o
r
a
l
D
e
s
i
g
n
P
a
t
t
e
r
n
The Strategy pattern allows for selection of
specific behavioral algorithms at
runtime,
since the selected strategy is just an attribute
of the class using the Strategy.
We can select particular behavioral strategies when
we constructed the Ducks
But since the swim() or quack() behaviors of Duck are
just attributes (references) to concrete Strategy
classes,
we could easily change the behaviors at any
time with a simple setSwimBehavior() mutator
method!
T
h
e
S
t
r
a
t
e
g
y
p
a
t
t
e
r
n
f
a
v
o
r
s
E
n
c
a
p
s
u
l
a
t
i
o
n
o
v
e
r
E
x
t
e
n
s
i
o
n
That is, rather than changing the behavior
implemented within a derived class by
extending
from a parent/base class, we
encapsulate
behaviors into a class as
instance attributes, which can be varied.
The Strategy pattern lets us
vary
and
change
behavioral algorithms independently of the
clients that use the behaviors.
A
g
o
o
d
D
e
s
i
g
n
P
a
t
t
e
r
n
h
a
s
a
l
s
o
s
o
l
v
e
d
a
l
a
r
g
e
r
c
o
n
c
e
p
t
u
a
l
i
s
s
u
e
:
To make a program easy to maintain, we
always want to strive for
1.
H
i
g
h
c
o
h
e
s
i
o
n
2.
L
o
w
c
o
u
p
l
i
n
g
SE-2811
Dr. Mark L. Hornick
16
C
o
u
p
l
i
n
g
:
H
o
w
c
l
o
s
e
l
y
t
w
o
o
r
m
o
r
e
c
l
a
s
s
e
s
a
r
e
r
e
l
a
t
e
d
Does changing code in one class require changes
in another class??
If “yes”, then it has high coupling (bad)
Changing swim or quack behaviors does not require
changes to the Duck class (low coupling)
Cohesion (?)
-- Grouping similar functionality in a single place in the
code
-- Few behavior in a class
-- Each class should have one focus
SE-2811
Dr. Mark L. Hornick
17
O
t
h
e
r
d
e
s
i
g
n
p
r
i
n
c
i
p
l
e
s
b
e
n
e
f
i
t
t
i
n
g
f
r
o
m
t
h
e
S
t
r
a
t
e
g
y
P
a
t
t
e
r
n
Decreases
coupling
, increases
cohesion
The behavior of the Duck is not coupled to the
Duck – behaviors are implemented separately.
Like all Design Patterns, the Strategy pattern
allows us to
vary a part of the system
(swim and
quack behavior) independently of other parts
O
t
h
e
r
g
o
o
d
d
e
s
i
g
n
p
r
i
n
c
i
p
l
e
s
w
e
v
i
s
i
t
e
d
Code to the highest level of abstraction that is
possible in a given context:
i.
ArrayList<Thing> = new ArrayList<Thing> // bad
ii.
List<Thing> = new ArrayList<Thing> // good
iii.
Collection<Thing> = new ArrayList<Thing> // better
O
t
h
e
r
g
o
o
d
d
e
s
i
g
n
p
r
i
n
c
i
p
l
e
s
w
e
v
i
s
i
t
e
d
Code to most restrictive level of access
modification that is possible in a given context:
i.
Use
public
for constants and methods; never for
attributes. On methods: only on those you want to
support for public consumption
ii.
Use /*package*/ if cooperating classes in the same
package need access to attributes or special
methods
iii.
Use
protected
to allow
derived
classes in
any
package access to members
iv.
Use
private
to completely guard members from
view outside the defining class
A
r
e
t
h
e
r
e
d
i
s
a
d
v
a
n
t
a
g
e
s
?
Yes: the implementation of the Strategy
Pattern is somewhat more complicated than
using inheritance
All design patterns usually exhibit this type of
tradeoff.
SE-2811
Dr. Mark L. Hornick
21
SE-2811
Dr. Josiah Yoder
The Strategy Design Pattern is a behavioral pattern that helps in encapsulating behaviors and varying them as attributes to avoid implementation inheritance and class explosions. By decoupling strategies from the main functionality, it allows for flexibility and ease in changing algorithms at runtime. This pattern involves a Context class that utilizes a specific behavior defined by a Strategy interface, with ConcreteStrategy classes implementing specific behaviors accordingly. Learn how to apply the Strategy Pattern effectively in your software design.
Uploaded on Oct 05, 2024 | 1 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
The Strategy Pattern Class 1-2 SE-2811 1 Dr. Mark L. Hornick
Review What problems are we trying to avoid? What do we want to achieve? SE-2811 2 Dr. Mark L. Hornick
A different approach: Isolate behaviors that vary, and encapsulate them as attributes to eliminate implementation inheritance and class explosions: SE-2811 3 Dr. Mark L. Hornick SimUDuck v5
Sorting Example Suppose we have a program that sorts Class objects Perhaps alphabetically, perhaps by closeness of fit Perhaps using Bubble Sort, or a (much better) algorithm like Merge Sort. SE-2811 4 Dr. Mark L. Hornick
Consider Collections.sort() Collections.sort() implements an argument which is a reference to a concrete class that implements the Comparator interface, and thus the behavior of the compare() method. Depending on the strategy of the compare() method in the concrete class, different sorting will be used by Collections.sort(). The comparison strategy is decoupled from the Collections.sort() method itself. SE-2811 5 Dr. Mark L. Hornick
Another sorting example Different strategies for sorting MergeSort O(NlogN) QuickSort O(NlogN) ShellSort In-place, (N(logN/log logN)2) InsertionSort O(N2) BubbleSort O(N2) Cool sorting algorithms of the future (or past) Would be nice to plug in new strategies SE-2811 Dr. Josiah Yoder 6 Idea: http://fuchangmiao.blogspot.com/2007/10/strategy-vs-observer.html
The Strategy Design Pattern in its general form: The Context is the class that encapsulates and uses a specific behavior, or Strategy. A Strategy is an interface that defines a behavior ConcreteStrategy classes implement specific behaviors
Applying the Strategy Pattern: Evidence 1 The Strategy Pattern is a behavioral pattern usually considered and applied at design-time. Premise: Your application requires similar objects whose behavior varies. SE-2811 8 Dr. Mark L. Hornick
Applying the Strategy Pattern: Evidence 2 As a designer, you watch for inheritance patterns that result in excessive behavior overrides and/or code duplication among classes. SE-2811 9 Dr. Mark L. Hornick
Applying the Strategy Pattern: Action! Leave behavior that is truly shared in abstract classes. Isolate behavior(s) that vary and declare interfaces that define those behaviors Implement the behaviors in separate concrete classes whose references can be passed to the Duck ctor SE-2811 10 Dr. Mark L. Hornick
Creating Ducks with specific behaviors // create some behaviors SwimBehavior csb = new CircularSwimming(); QuackBehavior sqb = new StandardQuacking(); SwimBehavior rsb = new RandomFloating(); // daffy has circular swimming, std quacking Waterfowl daffy = new Duck( daffy , csb, sqb); // donald has random floating, std quacking Waterfowl donald = new Duck( donald , rsb, sqb); daffy.swim(); donald.quack(); Dr. Mark L. Hornick SE-2811 11
Inside a Duck class // constructor public void Duck(String name, SwimBehavior sb, QuackBehavior qb) { super(name, sb, qb) } SE-2811 12 Dr. Mark L. Hornick
Inside a Waterfowl class public abstract class Waterfowl { private SwimBehavior swimBehavior; private QuackBehavior quackBehavior; private String name; // constructor public void Waterfowl(String name, SwimBehavior sb, QuackBehavior qb) { this.name = name; swimBehavior = sb; quackBehavior = qb; } // centralize implementation of behaviors in top-level classes // if possible; avoid duplication of behavior in subclasses. // Note we can make this method final to prevent subclasses from overriding it! public void swim() { swimBehavior.swim(); // invoke the specific behavior } SE-2811 13 Dr. Mark L. Hornick
Strategy is a Behavioral Design Pattern The Strategy pattern allows for selection of specific behavioral algorithms at runtime, since the selected strategy is just an attribute of the class using the Strategy. We can select particular behavioral strategies when we constructed the Ducks But since the swim() or quack() behaviors of Duck are just attributes (references) to concrete Strategy classes, we could easily change the behaviors at any time with a simple setSwimBehavior() mutator method!
The Strategy pattern favors Encapsulation over Extension That is, rather than changing the behavior implemented within a derived class by extending from a parent/base class, we encapsulate behaviors into a class as instance attributes, which can be varied. The Strategy pattern lets us vary and change behavioral algorithms independently of the clients that use the behaviors.
A good Design Pattern has also solved a larger conceptual issue: To make a program easy to maintain, we always want to strive for High cohesion 1. Low coupling 2. SE-2811 16 Dr. Mark L. Hornick
Coupling: How closely two or more classes are related Does changing code in one class require changes in another class?? If yes , then it has high coupling (bad) Changing swim or quack behaviors does not require changes to the Duck class (low coupling) Cohesion (?) -- Grouping similar functionality in a single place in the code -- Few behavior in a class -- Each class should have one focus SE-2811 17 Dr. Mark L. Hornick
Other design principles benefitting from the Strategy Pattern Decreases coupling, increases cohesion The behavior of the Duck is not coupled to the Duck behaviors are implemented separately. Like all Design Patterns, the Strategy pattern allows us to vary a part of the system (swim and quack behavior) independently of other parts
Other good design principles we visited Code to the highest level of abstraction that is possible in a given context: ArrayList<Thing> = new ArrayList<Thing> // bad List<Thing> = new ArrayList<Thing> // good Collection<Thing> = new ArrayList<Thing> // better i. ii. iii.
Other good design principles we visited Code to most restrictive level of access modification that is possible in a given context: Use public for constants and methods; never for attributes. On methods: only on those you want to support for public consumption Use /*package*/ if cooperating classes in the same package need access to attributes or special methods Use protected to allow derived classes in any package access to members Use private to completely guard members from view outside the defining class i. ii. iii. iv.
Are there disadvantages? Yes: the implementation of the Strategy Pattern is somewhat more complicated than using inheritance All design patterns usually exhibit this type of tradeoff. SE-2811 21 Dr. Mark L. Hornick
