1. SE 461 Software Patterns
Welcome to Design Patterns

2. Your problems are already solved,
How we can benefir from the experiences of other developers,
Instead of code reuse, with patterns you get experience reuse

3. A simple SimUDuck application:
Joe works for a company which makes duck pond simulation game, SimUDuck,
There are differen duck types,
Ducks quack and swim,
The initial designers of the system use OO techniques and created a Duck class. All other duck types derived from Duck class.

4. Company desigded to change the simulation:
They need the duck to FLY,

5. Solution found by Joe:
Add a fly() method in Duck class,
All the ducks will inherit it,

6. Problem of proposed solution by Joe:
In simulation there were rubber ducks flying around the screen!,

7. What happened:
All subclasses of Duck superclass should fly,
Joe added the fly() behaviour for subclasses for which it is not appropriate,

8. Inheritance is a good tool for reuse but not for maintenance.

9. Idea of Joe:
Override the fly behaviour of RubberDuck to do nothing!
Quack() {//squeak}
Display() {//rubber duck}
Fly(){ //override to do nothing}

10. What happens when we add decoy ducks:
DecoyDuck does not fly and quack.
Quack() {//override to do nothing}
Display() {//decoyduck}
Fly(){ //override to do nothing}

11. What about an interface:
- insisting on inheritance does not solves the problem,
- Take fly() method out of Duck class,
- Make a Flayable interface with fly() method,
- In that case only the ducks which supposed to fly will implement the interface and have fly() method.
- The idea can be applied to quack as well.

13. Think about the solution (interfaces):
- This solution completely destroys code reuse,

14. The one constant in software development:
- No matter how well you design an application, overtime an application must grow and change or it will die.
- Always count CHANGE in software development.

15. Consider again the problem:
- using inheritance was not a good idea,
- Flyable and Quackable interfaces sounded promising at first. But interfaces do not have implementations so no code reuse. -

16. Design principle:
Identify the aspects of your application that vary and seperate them from what stays the same.

17. Seperating what changes from what stays the same:
- Create two sets of classes: one for fly and one for quack,
- Each set of class will hold all the implementations of their respective behaviour,
- For example, we might have one class that implements quacking, another implements silance…

18. Seperating what changes from what stays the same:
- We know that, fly() and quack() are the parts of the Duck class that vary across ducks,
- We should seperate these behaviors from Duck class,
- Pull both methods out of the Duck class,
- Create a new set of methods to represent each behavior.

19. Designing the Duck Begaviors:
- We want to assign behaviours to the instances of Duck,
- We should include behavior setter methods.

20. Design principle:
Program to an interface, not an implementation.

21. So:
- Use an interface to represent a behavior,
- Duck class will not implement these interfaces,
- We will make a set of classes which implement the interfaces,

22. Implementing the Duck Behaviors:
- We have two interfaces: FlyBehavior, QuackBehavior,
- Corresponding set of classes implement the interfaces.

24. Implementing the Duck Behaviors:
-Duck will now delegate its flying and quacking behavior, instead of using quacking and flying methods defined in the Duck class.

25. Implementing the Duck Behaviors:
-First add two instance variables (flyBehavior, quackBehavior),
- Each Duck object will set these variables polymorphically to reference to specific behaviour type (FlyWithWings …)
- Remove fly() and quack() methods from Duck class,
- replce these methods with perfromFly(), performQuack() methods.

26. Implement performQuack:
public class Duck {
QuackBehavior quackBehavior; …
public void performQuack()
quackBehavior.quack(); }

27. How the flyBehavior and quackBehavior instance variables are set?
public class MallardDuck extends Duck {
public MallardDuck()
quackBehavior = new Quack();
flyBehavior = new FlyBehavior(); } …

28. Testing the Duck code: public abstract class Duck {
FlyBehavior flyBehavior;
QuackBehavior quackBehavior;
public Duck(){ }
public abstract void display();
public void performQuack()
quackBehavior.quack(); }
public vois swim()
System.out.prinln(“All ducks float, even decoys!”);

29. public interface FlyBehavior{
public void fly(); }
public class FlyWithWings implements FlyBehavior
public void fly()
System.out.println(“I’m flying!”);
public class FlyNoWay implements FlyBehavior
System.out.println(“I can’t fly!”);

30. public interface QuackBehavior{
public void quack(); }
public class Quack implements QuackBehavior
public void quack()
System.out.println(“Quack!”);
public class MuteQuack implements QuackBehavior
System.out.println(“Silance”);
public class Squeak implements QuackBehavior
System.out.println(“Squeak”);

31. public class MiniDuckSimulator{
public static void main(String[] args)
Duck mallard = new MallardDuck();
mallar.performQuack();
mallard.performFly(); }
java MiniDuckSimulator
Quack
I’m flying

32. Setting Behavior Dynamically
-We can use a setter method to set the behavior

33. Setting Behavior Dynamically
-We can use a setter method to set the behavior
- Add two methods to Duck class,
public void setFlyBehavior(FlyBehavior fb) {
flyBehavior = fb; }
public void setQuackBehavior(QuackBehavior qb)
quackBehavior = qb;

34. Setting Behavior Dynamically
-We can use a setter method to set the behavior
- Add two methods to Duck class,
- Make a new Duck type,
public class ModelDuck extends Duck {
public ModelDuck()
flyBehavior = new FlyNoWay();
quackBehavior = new Quack(); }

35. Setting Behavior Dynamically
-We can use a setter method to set the behavior
- Add two methods to Duck class,
- Make a new Duck type,
- Make a new FlyBehavor type,
public class FlyBehaviorPowered implements FlyBehavior {
public void fly()
System.out.println(“I’m flying with a rocket!”); }

36. Setting Behavior Dynamically
-We can use a setter method to set the behavior
- Add two methods to Duck class,
- Make a new Duck type,
- Make a new FlyBehavor type,
- Test it,
java MiniDuckSimulator
Quack
I’m flying
I can’t fly
I’m flying with a rocket
public class MiniDuckSimulator {
public static void main(String[] args)
Duck mallard = new MallardDuck();
mallar.performQuack();
mallard.performFly();
Duck model = new ModelDuck();
model.performFly();
model.setFlyBehavior(new FlyRocketPowered()); }

37. The Big Picture

38. HAS-A can be better than IS-A
-Each Duck has a FlyBehavior and a QuackBehavior,
- When you put twı classes together it is COMPOSITION,
- Composition encapsulate a familiy of algorithms into their own set of classes,
- Composition also lets you change behaviour at runtime.

39. Design principle:
Favor composition over inheritance.

40. The Strategy Pattern defines a familiy of algorithms, encapsulates each one, and makes them interchangable. Strategy lets the algorithm vary independently from clients that use it.

41. References