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
