design patterns n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
“Design Patterns” PowerPoint Presentation
Download Presentation
“Design Patterns”

Loading in 2 Seconds...

play fullscreen
1 / 20

“Design Patterns” - PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on

“Design Patterns”. A popular and influential software engineering text Published in 1995 amid upsurge of OO programming Triggered widespread and ongoing interest in patterns Often referred to as the “Gang of Four” (GoF) book Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

“Design Patterns”


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. “Design Patterns” • A popular and influential software engineering text • Published in 1995 amid upsurge of OO programming • Triggered widespread and ongoing interest in patterns • Often referred to as the “Gang of Four” (GoF) book • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides • Thanks to Stephen Jewett (CSE 432 Spring 2006) for the following ha-ha-only-serious observation: “Warning – Reading this Book May Cause an Uncontrollable Urge to Redesign Everything”

    2. GoF Book’s Preface • Assumptions about readers’ background • Familiarity with object-oriented design ideas • E.g., polymorphism, types, interface, implementation, etc. • A willingness to revisit (see iterator pattern :-) the ideas • What this book isn’t • A deeply technical or formal treatment of programming • I.e., other texts cover type theory, automata, algorithms, etc. • A recipe (or cookbook) for generating a design or designs • What this book is • A (potentially new) way of thinking about program design • A great source of small illustrative design examples • A resource to return to again and again as you design code

    3. GoF Book’s Forward • The GoF book’s forward was written by Grady Booch • An early leader in the development of object-oriented design • Founded Rational Software, which IBM later acquired • The Booch Method was merged with OMT to form UML • An important observation about software and patterns • Well structured object-oriented software is “pattern-rich” • “Collaborations” among objects are common (recurring) • This level of detail is crucial to crafting complex systems well • Connecting building and software architecture • Alexander et al. used patterns to characterize houses, cities • Gamma, Helm, Johnson, Vlissides showed how that idea can be translated to software systems

    4. GoF Book’s Guide to Readers • Multiple ways to read this book (we’ll use all 3 ways) • As a textbook: a primer, then a case study, then a catalog • As a design treatise: from common problems to specifics • On-demand: skipping around based on what you need • Suggestions for simple and common patterns to study • Abstract Factory • Adapter • Composite • Decorator • Factory Method • Observer • Strategy • Template Method

    5. GoF Book’s Introduction • Designing reusable object-oriented software is difficult • Objects, classes, interfaces, hierarchies, associations • Structure how these different features inter-relate in a design • Expert designers already know how to do this well • They also re-use solutions (or parts of solutions) that work • How can what they re-use be captured, and communicated? • Key idea is that the problems and their solutions recur • So we can document problems and solutions together • Design patterns do this recording, in an accessible form • Helps us remember patterns, and learn new ones

    6. What is a Design Pattern? (GoF 1.1) • A pattern has a name • So that we can refer to it, as part of a design vocabulary • A pattern documents a recurringproblem • Tells us when to apply the pattern, and in what contexts • A pattern describes the core of a solution • An approach that we can apply/adapt in different contexts • Not a recipe for a concrete design (not so narrow/limited) • A pattern documents resulting consequences • Possible trade-offs in applying that solution to that problem • New problems that may arise due to the use of the pattern

    7. Model-View-Controller Case Study (GoF 1.2) • A nice illustration of Grady Booch’s observation • Well-structured software (MVC vs. monolithic interfaces) • Evident patterns (Observer, Composite, Strategy, etc.) • Observation holds true even for many small examples • Thought question: is MVC itself a pattern? • Are a name, problem, solution, and consequences evident? • How general is its domain of applicability? • Can it be decomposed further into more fundamental patterns?

    8. Describing Design Patterns (GoF 1.3) • We said what features a pattern must have • a name, problem, solution, and consequences (inherent) • But, what else is useful to describe about a pattern? • GoF authors present one such layout in the book • “Intent” is particularly useful (see 1.4, inside front cover) • “Also known as” helps prune proliferation of names (a key merit of patterns lies in commonality rather than originality) • Structure/collaborations relate to design methodology (UML) • Sample code illustrates use of the pattern concretely • Known uses help document recurrence of the pattern • There are many other formats in the patterns literature • GoF format is merely one of the more popular ones • Each establishes a particular genre for describing patterns • And, some authors use some or all of a genre’s attributes

    9. A Catalog of Design Patterns (GoF 1.4, 3, 4, 5) • Each pattern’s name and intent are listed • Along with the page number in the GoF book where it starts • List is also inside the book’s front cover for quick access • Patterns are listed alphabetically by name in 1.4 • In the catalog they’re organized by category of purpose • I.e., creational, structural, or behavioral (Table 1.1 in 1.5)

    10. Catalog Organization (GoF 1.5) • GoF patterns are creational, structural, or behavioral • Creational patterns involve construction of new objects • Structural patterns involve static class/object relationships • Behavioral patterns involve dynamic (run-time) interactions • Apply (primarily) to classes, objects, or both • E.g., class form of adapter involves (private) inheritance • E.g., object form of adapter involves delegation

    11. How to Select a Design Pattern (GoF 1.7) • (We’ll come back to GoF section 1.6 in a moment) • Think concretely about your design problem (GoF 1.6) • Object/interface/implementation level structure matters • Everything you’ve already learned about design still applies • Look at the intent descriptions in 1.4 (as a quick index) • Think about how patterns interrelate in evolving design • See patterns map on page 12 in 1.6, and inside back cover • Would other patterns in the same category fit better? • Creational, structural, or behavioral • Watch and avoid causes of redesign (page 24 in 1.6) • Consider what should be fixed and what should vary • See table 1.2 on page 30

    12. How to Use a Design Pattern (GoF 1.8) • First, skim a pattern to determine whether its useful • Look especially at applicability and consequences • If it looks like a good match, study it more thoroughly • Understand classes, static and dynamic structure • Look at the code examples for implementation ideas • Start with high level design • Initially, name the participants in your design (descriptively, aptly, and clearly) • Make sure the participants fulfill pattern roles well • Move into low level design (specification of classes) • Lay out class members, interfaces, associations • Move from there into implementation • Define class methods, their interactions within the system

    13. How Patterns Solve Design Problems (GoF 1.6) • First, a few reminders/pointers to useful info • Patterns list inside front cover and on pages 8-9 • Patterns map inside back cover and on page 12 • Diagram notation in Appendix B and inside back cover • Section 1.6 focuses on how design patterns fit within established object-oriented development techniques • Patterns augment rather than replace existing methods • Section 1.6 follows standard design evolution described in section 1.8 • Begin with high-level design (identifying participants) • Move to low-level design (specify concrete relationships) • Move to implementation (define concrete behaviors)

    14. Finding Appropriate Objects • This should all be very familiar in OO design • An object combines data and behavior • An object plays a role within a program (does something) • Not all objects are immediately obvious • Try the “noun/verb” trick for spotting objects • A variant of the CRC approach (not part of GoF per se) • In any requirement, try to write as concretely as possible • Should have lots of description of what’s done by whom • Underline nouns in the description as potential objects • Underline verbs in the description as potential behaviors • Identifying object granularity and multiplicity also matters for pattern choice (flyweights vs. singletons)

    15. Specifying Object Interfaces • Pay attention to operations and their signatures • Name and ordered list of types supplied to an operation • Collect common sets of operations into cohesive abstractions (possibly organized hierarchically) • Allows polymorphic substitution of objects per subtyping

    16. Specifying Object Implementations • Once the interfaces are established, what’s left? • Need to identify necessary data to implement interface operations • Need to establish class relationships allowing substitution of objects passed as operation arguments • E.g., inheritance for object-oriented polymorphism • E.g., models relations for generic (interface) polymorphism • Need to establish other relationships like delegation, etc. based on interfaces rather than on implementations (so design isn’t brittle to changes)

    17. Putting Re-use Mechanisms to Work • Inheritance vs. composition • Inheritance of interface vs. implementation • Delegation as a powerful form of composition (allows replacement of target class even at run-time if necessary) • Inheritance vs. parameterized types • This has come a long way since 1995, but they anticipated several of the most important issues at least abstractly

    18. Relating Run-Time and Compile-Time Structures • Different languages have different compile time vs. run-time features (say, Smalltalk vs. C++) • Even within a language, these distinctions matter • Run-time polymorphism with C++ virtual member functions • Compile-time polymorphism with C++ templates and traits • Careful attention to when things can change as well as what can change is crucial to robust design

    19. Designing for Change • Change can be required at several different scales • Fine-grained time scale (e.g., run-time object substitution) • Medium-grained time scale (e.g., program updates) • Long-term time scale (e.g., system requirement evolution) • Designing for change is crucial to master • Pages 24 through 28 offer tips and ideas • With pointers to specific patterns that are relevant (a very nice guide to go back to again and again as you design) • Experience with when to worry about change also helps • Design with the idea that change is “looking over your shoulder” at all times

    20. Summary and Review Questions • The GoF book presents a useful design pattern genre • And a catalog of many important patterns described that way • The GoF book also motivates and describes the process of pattern-oriented design, with examples • E.g., MVC involving observer, strategy, composite, etc. • Thanks to Genevieve Gurney (CSE 432 Spring 2006) for the following review questions: “What are the four essential elements of a design pattern?” “What design issues don’t the GoF design patterns address?”