Scribd
Upload
62 views

Dao Tran Hoang Chau, MSC

The document discusses various approaches to modeling duck behavior in object-oriented programming. It starts with inheritance but finds issues when trying to model different types of ducks. It then explores using interfaces and strategy patterns to more flexibly model varying duck behaviors like flying and quacking.

Uploaded by

Trung Tran
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
62 views

Dao Tran Hoang Chau, MSC

The document discusses various approaches to modeling duck behavior in object-oriented programming. It starts with inheritance but finds issues when trying to model different types of ducks. It then explores using interfaces and strategy patterns to more flexibly model varying duck behaviors like flying and quacking.

Uploaded by

Trung Tran
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/ 25

Dao Tran Hoang Chau, MSc

 Various types of duck


◦ Mallard
◦ Redhead
 Various behaviours
◦ Swim
◦ Quack
 Many different ducks, but they are all ducks
 Inheritance
 Operations of Duck class:
◦ Swim
◦ Quack
◦ Display
 DuckPond class
◦ A duck pond has many ducks  Aggregation
◦ What type(s) of duck to be contained in the pond?
 Methods to display and update the ducks’
positions
 Well, ducks can fly, can’t they?
 Add a fly() method to Duck class
this.fly()  duck can now fly !!!
 What if a naughty kid puts in rubber ducks?
And your recent change made the ducks fly
off the pond. Wow!
 RubberDuck inherits fly() from Duck base
class
 Rubber ducks cannot fly
 RubberDuck inherits fly() method from
Duck base class
Flying behaviour is not appropriate for all
subclasses of Duck
 Rubber ducks do not fly
 Other duck types do
 Replace fly() in Duck base class with a does-
nothing method
 Someone likes to add decoy ducks
◦ Can’t fly
◦ Can’t quack either (oops!)
 Again, fly() and quack() need to be re-
written?
 Inheritance model doesn’t help... 
 Am I mentioning Graphical User Interface? NO
 Interface is a collection of methods that an
object implements
 Interfaces contain no code
 An object can support multiple interfaces
 Does the object supports certain interface(s)?
 If yes, it can use the interface, otherwise do
not implement the interface
 So we change our design (yet again!)
 Duck base class will only provides common
functions
 Flyable interface add support for flying
 Quackable interface addes support for
quacking
 Any subclasses of Duck base class only need
to implement appropriate interfaces
 Interfaces have no code  Each new subclass
must have its own implementation for each
interface
 If Flyable interface changes, every subclass
supporting it requires change as well
 Change = constant in software development
 Don’t make rigid designs for maintenance
◦ Corrective maintenance
◦ Perfective maintenace
◦ Enhancment maintenace
“Identify the aspects of your application that
vary
and separate them from what stays the
same”

 Encapsulate the bits that change according


to new requirements into a new object so that
it can be changed easily
 What vary in our simulation?
◦ All ducks can swim
◦ But not fly() and quack()
 Seperate fly() and quack() behaviours off
the new classes
 Flying Behaviours
 Quacking Behaviours
 Example of the Strategy Pattern
 Strategy Pattern defines a family of
algorithms, encapsulates each one, and
makes them interchangeable.
 Strategy lets the algorithm vary independently
from clients that use it
 Keep things flexible
 Can a rubber duck swim?
 Instances of Duck are assigned a behaviour
variable
 Mutators can change ducks’ behaviour at
run time
 Add instance variables for the behaviours
◦ flyBehaviour
◦ quackBehaviour
 Add methods to call the behaviour
public class Duck {
protected FlyBehaviour flyBehaviour;
protected QuackBehaviour quackBehaviour;

public void performQuack() {


quackBehaviour.quack();
}

public void display()}

public void performFly(){}

}
public class Mallard extends Duck {
flyBehaviour = new FlyWithWings;
quackBehaviour = new Quack();
public Mallard(){}

public void display(){


System.out.println(“Hello, I’m
a mallard.”);
}
}
 Commonly recurring patterns of OO design
 Solve complex problems
 Shared language
 Solution at hand

You might also like