1 / 22

CS 210

CS 210. Introduction to Design Patterns August 29, 2006. Head First: Design Patterns. Eric Freeman & Elisabeth Freeman O’Reilly Press, 2004. Introduction to Design Patterns. Chapter 1 Strategy Pattern. Goals for this week. Learn how to exploit and gain experience of others

jubal
Download Presentation

CS 210

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 210 Introduction to Design Patterns August 29, 2006

  2. Head First: Design Patterns Eric Freeman & Elisabeth Freeman O’Reilly Press, 2004

  3. Introduction to Design Patterns Chapter 1 Strategy Pattern

  4. Goals for this week • Learn how to exploit and gain experience of others • Examine the benefits of design pattern • Learn one specific pattern: Strategy pattern

  5. Duck quack() swim() display() // other duck methods Simple Simulation of Duck behavior RedheadDuck MallardDuck Other duck types display() // looks like redhead display() // looks like mallard

  6. Duck quack() swim() display() fly() // other duck methods What if we want to simulate flying ducks? RedheadDuck MallardDuck Other duck types display() // looks like redhead display() // looks like mallard

  7. Duck quack() swim() display() fly() // other duck methods RubberDuck RedheadDuck MallardDuck quack() //overridden to squeak display() // looks like rubberduck fly() // override to do nothing display() // looks like redhead display() // looks like mallard Tradeoffs in use of inheritance and maintenance One could override the fly method to the appropriate thing – just as the quack method below.

  8. DecoyDuck quack(){ // override to do nothing } display() // display decoy duck fly (){ //override to do nothing } Example complicated: add a wooden decoy ducks to the mix Inheritance is not always the right answer. Every new class that inherits unwanted behavior needs to be overridden. How about using interfaces instead?

  9. Quackable Flyable Duck quack() fly() swim() display() // other duck methods RubberDuck DecoyDuck display() quack() display() MallardDuck RedheadDuck display() fly() quack() display() fly() quack() Duck simulation recast using interfaces. Interfaces

  10. Pros and cons • Not all inherited methods make sense for all subclasses – hence inheritance is not the right answer • But by defining interfaces, every class that needs to support that interface needs to implement that functionality… destroys code reuse! • So if you want to change the behavior defined by interfaces, every class that implements that behavior may potentially be impacted And….

  11. Change is Constant In software development

  12. Design Principle Identify the aspects of your application that vary and separate them from what stays the same. OR Take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don’t.

  13. In the Duck simulation context… Parts that vary Parts that stay the same Duck Behaviors Flying Behaviors Duck Class Quacking Behaviors

  14. Design Principle • Program to an interface, not to an implementation. • Really means program to a super type.

  15. Program to an interface • Programming to an implementation Dog d = new Dog(); d.bark(); • Programming to an interface Animal animal = new Dog(); animal.makesound();

  16. <<interface>> FlyBehavior <<interface>> QuackBehavior fly() quack() FlyWithWings Quack FlyNoWay Squeak MuteQuack fly(){ // implements duck flying } quack(){ // implements duck quacking } fly(){ // do nothing – Can’t fly } quack(){ // implements duck squeak } quack(){ // do nothing – Can’t quack } Implementing duck behaviors - revisited

  17. Integrating the duck behavior • Key now is that Duck class will delegate its flying and quacking behavior instead of implementing these itself.

  18. Duck FlyBehavior: flyBehavior QuackBehavior: quackBehavior performQuack() swim() display() performFly() //other duck-like methods In the Duck simulation context… Duck Behaviors Flying Behaviors Quacking Behaviors

  19. <<interface>> FlyBehavior Duck fly() FlyBehavior: flyBehavior QuackBehavior: quackBehavior performQuack() performFly() setFlyBehavior() setQuackBehavior() swim() display() FlyWithWings FlyNoWay fly() // implements duck flying fly() // do nothing – Can’t fly <<interface>> QuackBehavior quack() DecoyDuck MallardDuck RubberDuck Quack Squeak quack() // implements squeak quack() // implements duck quacking RedHeadDuck display() display() display() display() Mutequack quack() // do nothing Duck simulation recast using the new approach

  20. Design Principle • Favor composition over inheritance • HAS-A can be better than IS-A • Allows changing behavior at run time

  21. The strategy pattern 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.

  22. Rationale for design patterns • Shared pattern vocabularies are powerful • Patterns allow you to say more with less • Reusing tried and tested methods • Focus is on developing flexible, maintainable programs

More Related