LECTURE 3:STRATEGY PATTERN –OR–BRINGING A KNIFE TO A GUNFIGHT

CSC 313 – Advanced Programming Topics

Bested by Lilliputians

Bested by Lilliputians

Bested by Lilliputians

fly behavior quack behavior

Bested by Lilliputians

fly behavior quack behavior

Lot of short ones beats a big, tall one

Implementing a Strategy

public interface FlyBehavior {public void fly();

}

public class UseJets implements FlyBehavior {public void fly() { System.out.println(“Vrooom”);}

}

public class Wings implements FlyBehavior {public void fly() { System.out.println(“Band On the Run”);}

}

Implementing a Strategy

public interface FlyBehavior {public void fly();

}

public class UseJets implements FlyBehavior {public void fly() { System.out.println(“Vrooom”);}

}

public class Wings implements FlyBehavior {public void fly() { System.out.println(“Band On the Run”);}

}

Using a Strategy

public interface FlyBehavior {public void fly();

}

public abstract class Duck {private FlyBehavior flyBehavior;public Duck(FlyBehavior f) { flyBehavior = f; }public void fly() { flyBehavior.fly(); }

}

public class PaulMcCartney extends Duck {public PaulMcCartney() { super(new Wings()); }

}

public class DecoyDuck extends Duck {public DecoyDuck() { super(new NoFly()); }

}

Strategy Pattern

Define supertype for family of algorithms interface used nearly always for this Entire family relies on method signature

specified Make algorithms interchangeable

Separate class encapsulates each algorithm

Algorithm definition split from its use Add algorithms easily with no changes to

code New environments can also reuse

algorithms

Zen & the Art of Programming

Identify and isolate what will change from what stays the same

What is being done split from how to do it

Program to a concept, not a class Client cannot know what Strategy does Strategy limited to working only with

parameters

Changing your Strategy

Strategy fixed only when client calls it Determined by value of field when the

call is made Set & change strategies at any time

Client does not know implementation to rely on it

Simply reassign field whenever it should change

All the Client subclasses may not be needed If only Strategy differs, just change

field’s value At worst, subclasses limited to a

constructor

Reusing a Strategy

public class JetFighter {private FlyBehavior flyBehavior;

public JetFighter() { flyBehavior = new UseJets();}

public void fly() { flyBehavior.fly();}

}

Reusing a Strategy

public class JetFighter {private FlyBehavior flyBehavior;

public JetFighter() { flyBehavior = new UseJets();}

public void fly() { flyBehavior.fly();}

}

Thanks to the Strategy Pattern, I had more time for

FarmVille!

Zen & Art of Programming

Favor composition over inheritance Composition is far easier to spell

Tools: Are They Worth It?

Good in correct environments & for correct uses

Tools: Are They Worth It?

Good in correct environments & for correct uses

Become an abomination in other situations

Tools: Are They Worth It?

Good in correct environments & for correct uses

Become an abomination in other situations

Making Tools Work

Use inheritance… …to have class expand concepts in

superclass …not add or modify behavior that is

inherited Use Strategy Pattern…

…for single concept with multiple behaviors

Zen & the Art of Programming

Favor composition over inheritance Inheritance has problems

Specify when written; cannot change dynamically

Limits use & re-use of classes to original concept

Makes adding & mixing functionality difficult

Composition imperfect also Can make debugging more difficult Requires more classes & interfaces to

work With composition, optimizations may not

occur

For Next Lecture

Read pages 26 - 32 How do you talk about a program? What do you write in your

documentation? What do wish others documentation

would say? What makes for good design? Ever seen beautiful code? What made it

pretty?