1. D ESIGN P ATTERNS Introduction

2. C OURSE D ESCRIPTION Traditionally, OO designers have developed their own private "catalogs" of solutions to recurring design problems. More recently, advocates of design patterns have created public repositories of patterns that more formally Identify these recurring design problems Document possible solutions to these problems through the general arrangement and composition of objects and classes Discuss the advantages and disadvantages of the various solutions and Provide implementation examples. This course will introduce the student to the concept of design patterns, examine several patterns in detail, apply these patterns to specific problems, and point the student to design pattern resources. 2

3. R ECOMMENDED T EXTBOOKS Recommended Text Design Patterns: Elements of Reusable Object- Oriented Software (1995) by Gamma; ISBN 0-201- 63361-2 published by Pearson Education Additional Reading Head First Design Patterns (2004) by Freeman; ISBN 0-596-00712-4 published by O'Reilly and Assoc. 3

4. M ARKS D ISTRIBUTION 6-8 Quizzes: 15% 2 Assignments: 25% Mid term Exam:30% Final Exam: 30% 4

5. O UTLINE Introduction to Design Patterns Describing Design Patterns The Design Patterns Catalog How to Select and Use a Design Pattern Creational Patterns Abstract Factory, Builder, Singleton etc. Structural Patterns Adapter, Bridge, Composite etc. Behavioral Patterns Command, Interpreter, Observer, Strategy etc. 5

6. W HAT ’ S A GOOD OBJECT ORIENTED DESIGN Design should be SPECIFIC to the problem at hand AND Also be GENERIC enough to address future problems and requirements So the design should be REUSABLE Expert designers REUSE successful designs Consequently REUSABLE designs are recurring PATTERNS of classes and objects in OO Systems 6

7. REUSABILITY EXAMPLE Novelists & Playwrights seldom write from scratch INSTEAD Follow PATTERNS like ‘Tragically flawed Hero’ (Macbeth, Hamlet) or ‘The Romantic Novel’ 7

8. W HAT IS A DESIGN PATTERN “A proven solution to a common problem in a specified context.” Example: We can light a candle if light goes out at night Christopher Alexander (Civil Engineer) in 1977 wrote “A pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” The “gang of four” (GoF) In 1995, the principles that Alexander established were applied to software design and architecture. The result was the book: “Design Patterns: Elements of Reusable Object-Oriented Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 8

9. W HY LEARN D ESIGN P ATTERNS They make it easier to reuse successful designs and architectures They can make documentation and maintenance of the systems easier Design Patterns help a designer design “right” faster They provide a vocabulary that can be used amongst software developers. Enable us to discuss low-level implementation in a high-level, abstract manner. Help in extendibility and avoiding solution redesign 9

10. E LEMENTS OF A D ESIGN P ATTERN Pattern Name Is a handle to describe design problem & solution Problem Describes when a Pattern is to be applied Solution General arrangement of elements to solve a problem Consequences Results and Tradeoffs of applying a Pattern Tradeoffs can be space, time, language etc. 10

11. D ESCRIBING A D ESIGN P ATTERN Pattern Name & Classification – Conveys the essence of the pattern concisely Intent – What design issue the pattern addresses Also Known As – Other well known names for this pattern Motivation – A scenario illustrating a design problem and how its being solved by the pattern Applicability – Known situations where the pattern can be applied Structure – OMT (Object Modeling ) based graphic representation of the classes in the pattern Participants – Classes and objects in the pattern with their responsibilities 11

12. D ESCRIBING A D ESIGN P ATTERN C ONT ’ D Collaborations – How the participants collaborate to carry out their responsibilities Consequences – What are the results and tradeoffs of using the pattern Implementation – Hints on implementation of the pattern like language dependency Sample Code – Sample code Known Uses – Examples Related Patterns – Other patterns closely related with the pattern under consideration 12

13. N OT A D ESIGN P ATTERN Linked Lists Hash Tables Domain Specific designs for entire application or subsystem A code solution ready for copy-and-paste Programming language features The same every time you see them 13

14. MVC P ATTERN The main purpose of using MVC pattern is to decouple the GUI from the Data. It also gives the ability to provide multiple views for the same Data. MVC pattern separates views and models by establishing a subscribe/notify protocol amongst them Application of MVC pattern has benefits like Classes defining application data and presentation can be reused. Change in one view automatically reflected in other views. Also, change in the application data is reflected in all views. Defines one-to-many dependency amongst objects so that when one object changes its state, all its dependents are notified 14

15. MVC P ATTERN C ONT ’ D A=10% B=40% C=30% D=20% Application data A B C D ADCB Relative Percentages Y10 40 30 20 X15 35 35 15 Z10 40 30 20 A B C D Change notification Requests, modifications Model 15

16. MVC P ATTERN C ONT ’ D Model : - This section is specially for maintaining data. It is actually where your business logic, querying database, database connection etc. is actually implemented. Views : - Displaying all or some portion of data, or probably different view of data. View is responsible for look and feel, Sorting, formatting etc. Controller : - They are event handling section which affects either the model or the view. Controller responds to the mouse or keyboard input to command Model and View to change. Controllers are associated with views. User interaction triggers the events to change the Model, which in turn calls some methods of Model to update its state to notify other registered Views to refresh their display. 16

17. D ESIGN P ATTERNS C LASSIFICATION According to the GOF, the design patterns can be classified in two ways According to the PURPOSE According to the SCOPE PURPOSE of Design Patterns reflect what actually they do SCOPE of Design Patterns reflect whether they apply primarily to Classes or Objects. 17

18. P URPOSE BASED D ESIGN P ATTERNS C LASSIFICATION Creational – Concerned with the purpose of object creation or class instantiation Structural – Deal with composition of classes and objects Behavioral – Characterize the ways in which classes and objects interact and distribute resposibility. 18

19. S COPE B ASED D ESIGN P ATTERNS C LASSIFICATION Class Patterns deals with the relationships amongst the classes and their subclasses These relationships are established through INHERITANCE, so they are static – fixed at compile time Object Patterns deals with object relationships which can be changed at runtime or are dynamic Note that most patterns are object patterns 19

20. P URPOSE & S COPE BASED D ESIGN P ATTERNS C LASSIFICATION Creational Class patterns defer some part of object creation to subclasses where as creational object patterns defer it to another object. Structural class patterns use inheritance to compose classes, while structural object patterns describe ways to assemble objects. Behavioral class patterns use inheritance to describe algorithms and flow of control, whereas the behavioral object patterns describe how a group of objects cooperate to perform a task 20

21. D ESIGN P ATTERNS C LASSIFICATION Purpose CreationalStructuralBehavioral Scope Class Factory MethodAdapter(Class)Interpreter Template Method Object Abstract Factory Builder Prototype Singleton Adapter(Object) Bridge Composite Decorator Façade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 21

22. H OW D ESIGN P ATTERNS S OLVE D ESIGN P ROBLEMS Finding appropriate objects The hard part about OOD is decomposing a system into objects They help to introduce an abstraction for treating objects uniformly that doesn’t have a physical counterpart They help to identify less obvious abstractions and objects that can capture them These objects are seldom identified in a design earlier and are discovered while making the design reusable and more flexible Determining the object Granularity They help in specifying how to represent complete subsystems as objects They help you in decomposing objects into smaller objects 22

23. H OW D ESIGN P ATTERNS S OLVE D ESIGN P ROBLEMS Specifying Object Interfaces Help you in defining interfaces and the kinds of data that get sent across them Might also tell what NOT to put into an interface Also specify relationships across interfaces Designing for Change Help you to avoid dependence on specific operations Help you to avoid dependence on hardware and software platforms Help to avoid algorithmic dependencies 23

24. P ATTERNS AND A LGORITHMS Algorithms and data structures generally solve more fine-grained computational problems like sorting and searching. Patterns are typically concerned with broader architectural issues that have larger-scale effects. 24

25. P ATTERNS AND F RAMEWORKS A software framework is a set of cooperating classes that make up a reusable design for a specific class of software [Deu89,JF88] A framework will dictate overall structure, partitioning of classes and objects, how the classes or objects collaborate A framework is usually not a complete application: it often lacks the necessary application-specific functionality. Examples Framework for building compiler for different languages and machines. For building financial modeling applications 25

26. P ATTERNS AND F RAMEWORKS Design patterns may be employed both in the design and the documentation of a framework. A single framework typically encompasses several design patterns. A framework can be viewed as the implementation of a system of design patterns. Frameworks and design patterns are distinct: a framework is executable software, design patterns represent knowledge and experience about software. Frameworks are of a physical nature, patterns are of a logical nature: frameworks are the physical realization of one or more software pattern solutions; patterns are the instructions for how to implement those solutions. Major differences: Design patterns are more abstract than frameworks. Design patterns are smaller architectural elements than frameworks. Design patterns are less specialized than frameworks. 26

27. A N E XAMPLE C ASE Goals Learn how to exploit and gain experience of others Examine the benefits of design pattern Learn one specific pattern: Strategy pattern 27

28. S IMPLE S IMULATION OF D UCK BEHAVIOR Duck quack() swim() display() // other duck methods MallardDuck display() // looks like mallard RedheadDuck display() // looks like redhead Other duck types 28

29. S IMPLE S IMULATION OF D UCK BEHAVIOR All ducks Quack and Swim the super class DUCK takes care of the implementation code. But Each duck subtype is responsible for implementing its own Display method as each duck looks different In the super class the Display method is abstract. 29

30. W HAT IF WE WANT TO SIMULATE FLYING DUCKS ? Duck quack() swim() display() fly() // other duck methods MallardDuck display() // looks like mallard RedheadDuck display() // looks like redhead Other duck types 30

31. T RADEOFFS IN USE OF INHERITANCE AND MAINTENANCE Duck quack() swim() display() fly() // other duck methods MallardDuck display() // looks like mallard RubberDuck quack() //overridden to squeak display() // looks like rubberduck fly() // override to do nothing RedheadDuck display() // looks like redhead One could override the fly method to the appropriate thing – just as the quack method below. 31

32. E XAMPLE COMPLICATED : ADD A WOODEN DECOY DUCKS TO THE MIX DecoyDuck quack(){ // override to do nothing } display() // display decoy duck fly (){ //override to do nothing } Inheritance is not always the right answer. Every new class that inherits unwanted behavior needs to be overridden. How about using interfaces instead? 32

33. U SING I NTERFACES IN O UR E XAMPLE We can take Fly() out of the superclasses We make an interface iFlyable containing the Fly() method. That way the ducks supposed to fly can implement that interface and have a Fly() method Same solution can be implemented for Quack(), we can make interface iQuackable containing the Quack() method 33

34. D UCK SIMULATION RECAST USING INTERFACES Duck swim() display() // other duck methods MallardDuck display() fly() quack() Quackable quack() Flyable fly() RedheadDuck display() fly() quack() RubberDuck display() quack() DecoyDuck display() Interfaces 34

35. P ROS & C ONS 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 and creates a maintenance issue. So if you want to change the behavior defined by interfaces, every class that implements that behavior may potentially be impacted AND Change is constant in Software Development Overtime an application must change and grow or it will die… 35

36. D ESIGN P RINCIPLES TO THE R ESCUE 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. Program to an interface, not to an implementation (Discussed Later) 36

37. C HANGE IN D UCK C LASSES A CCORDING TO THE D ESIGN P RINCIPLE As far as we can tell other than the problems with Fly() and Quack() the Duck Class is fine. Now to separate “the parts that change from those which remain the same”, we can create two sets of classes apart from the Duck Class. One set can represent the Quacking behaviors e.g. a class implements quacking, another implements squeaking etc. Similar is the case with Flying behaviors 37

38. 38

39. D ESIGN P RINCIPLE Program to an interface, not to an implementation We will use interfaces to represent each behavior Each Implementation of behavior will implement these interfaces So the duck classes won’t implement these interfaces instead the set of classes for behavior would implement them. With our new design the duck classes would USE a behavior represented by an interface. OR The actual implementation won’t be locked in the duck classes. 39

40. I MPLEMENTING DUCK BEHAVIORS - REVISITED FlyWithWings fly(){ // implements duck flying } > FlyBehavior fly() > QuackBehavior quack() Quack quack(){ // implements duck quacking } FlyNoWay fly(){ // do nothing – Can’t fly } Squeak quack(){ // implements duck squeak } MuteQuack quack(){ // do nothing – Can’t quack } Key now is that Duck class will delegate its flying and quacking behavior instead of implementing these itself 40

41. I N THE D UCK SIMULATION CONTEXT … 41 Duck FlyBehavior: flyBehavior QuackBehavior: quackBehavior performQuack() swim() display() performFly() //other duck-like methods Duck Behaviors 41

42. D UCK SIMULATION RECAST USING THE NEW APPROACH 42 MallardDuck display() RedHeadDuck display() RubberDuck display() DecoyDuck display() Duck FlyBehavior: flyBehavior QuackBehavior: quackBehavior performQuack() performFly() setFlyBehavior() setQuackBehavior() swim() display() > FlyBehavior fly() FlyWithWings fly() // implements duck flying FlyNoWay fly() // do nothing – Can’t fly > QuackBehavior quack() Quack quack() // implements duck quacking Squeak quack() // implements squeak Mutequack quack() // do nothing

43. D ESIGN P RINCIPLE Favor composition over inheritance HAS-A can be better than IS-A Composition lets you encapsulate a family of algorithms into their own set of classes. Allows changing behavior at run time 43

44. T HE STRATEGY PATTERN 44 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.