1. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Design Patterns

2. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Motivation/Background (1) –Developing software is hard –Developing reusable software is even harder –Leverage proven solutions to common problems –Two ways to do this: Frameworks –Support reuse of detailed design and code –Integrated set of components that provide partial solutions to problems Design Patterns –Support reuse of architectural design –Capture static and dynamic structures and collaborations of successful solutions

3. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Motivation/Background (2) –How do you become a software design master? Learn the foundations –Algorithms, data structures, programming languages Learn the principles of good design –Abstraction, encapsulation, and modularity –Open-closed, single responsibility, interface segregation, etc. Study the designs of masters –Understand, memorize, mimic Practice –Hands-on experience, multiple situations

4. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Intro to Design Patterns –Represent well-understood, good solutions to common problems that arise in a particular context –Particularly useful for Ease of modification Ease of reuse Ease of extension A good design is revealed when you attempt to change it

5. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. An Example: The Observer Design Pattern (1) –Sample application: stock quote service –Intent: define one-to-many dependency between objects so that when one object changes state, all its dependent objects are notified

6. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. An Example: The Observer Design Pattern (2) –Key points: There may be many observers Each observer may react differently to the same notification The observable should be decoupled from the observers to allow them to change independently Observers should be able to query observable for required information

7. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. An Example: The Observer Design Pattern (3) –Structure of the Design Pattern: Not really necessary

8. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. An Example: The Observer Design Pattern (4) –Collaboration of the Design Pattern: Not needed

9. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Structure of Design Patterns (1) –Divided by scope and purpose Scope –Does it apply to classes or objects –Class Patterns deal with relationships between classes »Static – compile-time relationships »Frequently involve inheritance »Not the typical design pattern –Object Patterns deal with relationships between objects »Dynamic – change at run-time »Frequently involve aggregation/delegation

10. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Structure of Design Patterns (2) –Divided by scope and purpose Purpose –What the pattern does –Three categories »Structural Patterns »Creational Patterns »Behavioral Patterns Structural Patterns –Deal with decoupling interface and implementation –Set the system up for modification –Examples: »Adapter – translate one interface to another »Composite – recursive aggregation

11. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Structure of Design Patterns (3) –Divided by scope and purpose Creational Patterns –Initialization and configuration –Examples »Singleton – controlled instance count »Factory Method – use inheritance to create instances of abstract classes Behavioral Patterns –Dynamic interactions among objects/classes –Examples: »Iterator – give sequential access to collection »Template Method – separate variant and invariant aspects of process

12. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Structure of Design Patterns (4) –What makes a pattern a “pattern” ? Describe a problem –A problem that arises frequently –Explains forces at work »E.g., Aspects that must be changed frequently Present a solution –Proven solution to the problem –Must indicate how it balances the active forces –Must define both static and dynamic aspects of solution

13. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Structure of Design Patterns (5) –What makes a pattern a “pattern” ? Have a context –Must indicate when/where the solution can be used –Describes the situation in which the problem arises Recur –Must be relevant to more than one situation Teach –Must provide sufficient understanding to allow it to be tailored Name

14. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Key Principles of Design Patterns –Separate interface from implementation Program to the interface, not the implementation –Separate variant from invariant aspects Define what is likely or desirable to change Build in flexibility for variant aspects –Prefer aggregation/delegation over inheritance Use aggregation to extend existing code (Creates “black box” reuse) Inheritance is for defining abstract hierarchies –Open/Closed Principle Open to extension, closed to modification (Easy to extend, does not require modification to do so)

15. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Key Benefits of Design Patterns –Large-scale reuse of class architecture Above the single class level –Capture expert knowledge/tradeoffs –Improve developer communication Own vocabulary Encourage documentation/review

16. Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Key Drawbacks of Design Patterns –No direct code reuse Language-independent Must be recoded each time –Deceptively simple Leads to misuse –Overload Can be too many patterns to find what you want –Validated only through experience/discussion No formal testing of design patterns –Overly abstract Leads to misunderstanding –Refactoring development process takes time Several attempts to understand how/when to use