1 / 30

Chapter 1

Chapter 1. Introduction. Design Patterns Elements of Reusable Object-Oriented Software. Overview. the issue what design patterns are what they’re good for how we develop & categorize them. Motivation & Concept. OOD methods emphasize design notations Fine for specification, documentation

mercer
Télécharger la présentation

Chapter 1

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. Chapter 1 Introduction Design PatternsElements of Reusable Object-Oriented Software

  2. Overview • the issue • what design patterns are • what they’re good for • how we develop & categorize them

  3. Motivation & Concept OOD methods emphasize design notations Fine for specification, documentation But OOD is more than just drawing diagrams Good draftsmen  good designers Good OO designers rely on lots of experience At least as important as syntax Most powerful reuse is design reuse Match problem to design experience

  4. Recurring Design Structures OO systems exhibit recurring structures that promote • abstraction • flexibility • modularity • elegance Therein lies valuable design knowledge Problem:capturing, communicating, & applying this knowledge

  5. A Design Pattern… • abstracts a recurring design structure • comprises class and/or object • dependencies • structures • interactions • conventions • names & specifies the design structure explicitly • distills design experience

  6. Four Basic Parts of a Design Pattern • Name • Problem (including “forces”) • Solution • Consequences & trade-offs of application Language- & implementation-independent A “micro-architecture” Adjunct to existing methodologies (RUP, Fusion, SCRUM, etc.)

  7. The MVC Architecture • MVC Consists of three kinds of objects • The Model is the application object • The View is the model’s screen presentation • The Controller defines the way the user interface reacts to user input • Establishes a subscribe/notify protocol between models and views • Main relationships in MVC are given by the Observer (M), Composite (V), and Strategy (C) design patterns

  8. Example: OBSERVER

  9. Goals Codify good design • distill & generalize experience • aid to novices & experts alike Give design structures explicit names • common vocabulary • reduced complexity • greater expressiveness Capture & preserve design information • articulate design decisions succinctly • improve documentation Facilitate restructuring/refactoring • patterns are interrelated • additional flexibility

  10. Classification of Design Patterns • Design patterns are classified based on two criteria - • Purpose – reflects what a pattern does • Creational – concern the process of object creation • Structural – deal with the composition of classes or objects • Behavioral – characterize the ways in which classes or objects interact and distribute responsibility • Scope – specifies whether the pattern applies primarily to classes or to objects • Class patterns – deal with relationships between classes and their subclasses; fixed at compile time; static in nature • Object patterns – deal with object relationships, which can be changed at run-time and are more dynamic

  11. Design Pattern Space

  12. Design Pattern Template (1st half)NAME scope purpose Intent short description of the pattern & its purpose Also Known As Any aliases this pattern is known by Motivation motivating scenario demonstrating pattern’s use Applicability circumstances in which pattern applies Structure graphical representation of the pattern using modified UML notation Participants participating classes and/or objects & their responsibilities

  13. Design Pattern Template (2nd half) ... • Collaborations • how participants cooperate to carry out their responsibilities • Consequences • the results of application, benefits, liabilities • Implementation • pitfalls, hints, techniques, plus language-dependent issues • Sample Code • sample implementations in C++, Java, C#, Smalltalk, C, etc. • Known Uses • examples drawn from existing systems • Related Patterns • discussion of other patterns that relate to this one

  14. Modified UML/OMT Notation

  15. Structure OBSERVER object behavioral Intent define a one-to-many dependency between objects so that when one object changes state, all dependents are notified & updated Applicability • an abstraction has two aspects, one dependent on the other • a change to one object requires changing untold others • an object should notify unknown other objects

  16. OBSERVER (cont’d) object behavioral Consequences • modularity: subject & observers may vary independently • extensibility: can define & add any number of observers • customizability: different observers offer different views of subject • unexpected updates: observers don’t know about each other • update overhead: might need hints or filtering Implementation • subject-observer mapping • dangling references • update protocols: the push & pull models • registering modifications of interest explicitly Known Uses • Smalltalk Model-View-Controller (MVC) • InterViews (Subjects & Views, Observer/Observable) • Andrew (Data Objects & Views) • Pub/sub middleware (e.g., CORBA Notification Service, Java Message Service) • Mailing lists

  17. Benefits of Patterns • Design reuse • Uniform design vocabulary • Enhance understanding, restructuring, & team communication • Basis for automation • Transcends language-centric biases/myopia • Abstracts away from many unimportant details

  18. Liabilities of Patterns • Require significant tedious & error-prone human effort to handcraft pattern implementations design reuse • Can be deceptively simple uniform design vocabulary • May limit design options • Leaves some important details unresolved

  19. Guide to Notation Appendix B + Chapter 1

  20. Guide to Notation • Three different diagrammatic notations are used • A class diagram depicts classes, their structure, and the static relationships between them • An object diagram depicts a particular object structure at run-time • An interaction diagram shows the flow of requests between objects

  21. Class Diagram (1) • Abstract and concrete classes • Relationships between classes (uses different symbols) • Inheritance (triangle) • Part-of or aggregation (arrowheaded line with a diamond at the base) • Acquaintance (arrowheaded line without diamond) • “Creates” (dashed arrowheaded line) • Reference to single or multiple objects (filled circle) • Pseudocode annotations

  22. Class Diagram (2) AbstractClassName AbstractOperation1() Type AbstractOperation2() ConcreteClassName Operation1() Type Operation2() instanceVariable1 Type instanceVariable2 Abstract and concrete classes

  23. Class Diagram (3) More than one shapes Drawing Shape Inheritance Aggregation CreationTool LineShape Color Creates Acquaintance Class Relationships

  24. for each shape { shape->Draw()} Class Diagram (4) Drawing Draw() Pseudocode annotation

  25. Class Diagram (5) ExistingClass Mixin ExistingOperation() MixinOperation() AugmentedClass ExistingOperation()MixinOperation() Mixin Class (Multiple Inheritance)

  26. Object Diagram (1) • Shows instances exclusively • Provides a snapshot of the objects in a design pattern • The objects are named “aSomething”, where Something is the class of the object

  27. Object Diagram (2) aDrawingshape[0] shape[1] aLineShape aCircleShape Object diagram notation

  28. Interaction Diagram (1) • Shows the order in which requests between objects get executed • Time flows from top to bottom • A solid vertical line indicates the lifetime of a particular object • The vertical line of an object appears dashed until the point of its creation • A vertical rectangle shows that an object is active • Horizontal arrow: request for an operation • Dashed arrowheaded line: request to create an object

  29. Interaction Diagram (2) aCreationTool aDrawing aLineShape new LineShape Add(aLineShape) Refresh() Draw() Interaction diagram notation

  30. Chapter 1 - Syllabus • Contents of the slides and relevant sections from the text book • Page – 1 – 8, 9 – 11 • Appendix B - Full

More Related