VIEWS: 7 PAGES: 20 POSTED ON: 6/23/2012
Chapter 1: Introduction to Design Patterns SimUDuck Example Duck quack() swim() display() Mallard RedheadDuck other ducks... display() display() System Update • Revise the current system to cater for ducks that fly. How can this be done? A Possible Solution Duck quack() Suppose that a RubberDuck swim() class needs to be added? fly() display() other ducks... MallardDuck RedheadDuck display() display() Revision: Use Inheritance? Duck Suppose that you have to add quack() a decoy duck that does not fly swim() or quack… fly() display() MallardDuck RedheadDuck RubberDuck display() display() display() quack() fly() Another Solution: Interfaces • The aspects that change for each type of duck are the methods fly() and quack(). • Take these methods out of the Duck class. • Create interfaces for these methods: – Flyable – has a method fly() – Quackable – has a method quack() Using Interfaces Flyable Quackable Duck fly() quack() swim() display() MallardDuck RedheadDuck RubberDuck DecoyDuck display() display() display() display() fly() fly() quack() quack() quack() Problems with this? Disadvantages of the Approach • All methods in Java interfaces are abstract. • Code has to be duplicated for classes. • Modification will have to be made to more than one class. • This will introduce bugs. Design Principle • Identify the aspects of the application that vary and separate them from what stays the same. • Encapsulate the parts that vary. • Future changes can be made without affecting parts that do not vary. • Results in fewer unexpected consequences from code change. Solution • Design principle: Program to interface and not to implementation. • An interface FlyBehavior will be implemented by subclasses for different types of flight. • An interface Quackable will be implemented for different types of “quack”. Example Animal makeSound() Abstract class OR Interface Dog Cat makeSound() makeSound() FlyBehavior Interface FlyBehavior fly() FlyWithWings FlyNoWay fly() fly() QuackBehavior QuackBehavior quack() Quack Squeak MuteQuack quack() quack() quack() New Design Duck QuackBehvior FlyBehvior has a <<interface>> <<interface>> has a swim() display() quack() fly() performFly() performQuack() MallardDuck RedheadDuck RubberDuck DecoyDuck display() display() display() display() On Last Problem • Still programming to implementation in the subclasses. • Solution – include set methods in the Duck class – To set quack behavior – To set fly behavior • The set methods allow for behavior to be dynamic at runtime Exercise • Add a new type of duck to the simulator, namely, model duck. A model duck does not fly and quacks. • Add a new fly behavior to the simulator, namely, FlyRocketPower, which represents flight via a rocket. • Create an instance of a model duck and change its behaviour at runtime to be flight via a rocket. Has-A Can be Better than Is-A • Inheritance promotes reuse but not extensibility. • Composition facilitates more flexibility. • Composition allows for behavior to change at runtime (rather than editing code). • Design principle: Favor composition over inheritance. The 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. Lessons Learned from the Strategy Pattern • Encapsulate what varies. • Favor composition over inheritance. • Program to interfaces, not implementations Advantages of Sharing a Pattern Vocabulary • Shared pattern vocabularies are powerful. • Patterns allow you to say more with less. • Talking at the pattern level allows to stay “in design” longer. • Shared vocabularies can turbo charge your development. • Shared vocabularies encourage more junior developers to get up to speed.
Pages to are hidden for
"Chapter 1_ Introduction to Design Patterns"Please download to view full document