CS6201 Software Reuse - Design Patterns

5,109 views

Published on

CS6201 Software Reuse - Design Patterns

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,109
On SlideShare
0
From Embeds
0
Number of Embeds
77
Actions
Shares
0
Downloads
332
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • A design pattern has 4 essential elements:
    1. The pattern name is a handle we can use to describe a design problem, its solutions, and consequences; it usually consists of one or two words.
    2. The problem describes when to apply the pattern.
    3. The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations.
    4. The consequences are the results and trade-offs of applying the pattern.
  • Design Pattern Space
    1. Creational patterns
    -. Deal with initializing and configuring classes and objects
    2. Structural patterns
    -. Deal with decoupling interface and implementation of objects
    3. Behavioural patterns
    -. Deal with dynamic interactions among societies of classes and objects
  • Information Systems
    -. Presentation
    -. Application logic
    -. Domain layer
    -. Database
  • CS6201 Software Reuse - Design Patterns

    1. 1. Design PatternsDesign Patterns 6 March 20076 March 2007 National University of SingaporeNational University of Singapore School of ComputingSchool of Computing OH KWANG SHINOH KWANG SHIN
    2. 2. Design Patterns 6 March 2007 2 AgendaAgenda • Origin of Pattern • Software Design Patterns • Why Use Patterns? • Describing Design Patterns • Architectural Pattern • Pattern System • Drawbacks of Patterns
    3. 3. Design Patterns 6 March 2007 3 Origin of PatternOrigin of Pattern
    4. 4. Design Patterns 6 March 2007 4 Origin of PatternOrigin of Pattern
    5. 5. Design Patterns 6 March 2007 5 Origin of PatternOrigin of Pattern
    6. 6. Design Patterns 6 March 2007 6 Origin of PatternOrigin of Pattern  Each 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 - Christopher Alexander (Architect) [AIS+ 77, page x] “ ”
    7. 7. Design Patterns 6 March 2007 7 Origin of PatternOrigin of Pattern • “A Pattern Language” – Berkeley architecture professor Christopher Alexander in 1977 – Patterns for • City planning • Landscaping – Architecture • In an attempt to capture principles for “living” design
    8. 8. Design Patterns 6 March 2007 8 Example 167 (page 783)Example 167 (page 783) 6ft Balcony6ft Balcony
    9. 9. Design Patterns 6 March 2007 9 History ofHistory of Software Design PatternSoftware Design Pattern • “Using Pattern Languages for Object- Oriented Programs” – Kent Beck and Ward Cunningham, Tektronix, Inc. – OOPSLA-87 Workshop – Used Alexander’s “Pattern” ideas for designing window-based user interfaces – Lack of the concrete illustration
    10. 10. Design Patterns 6 March 2007 10 History ofHistory of Software Design PatternSoftware Design Pattern • “Design Patterns: Elements of Reusable Object-Oriented Software” – Erich Gamma, Richard Helm, Ralph Johnson, John Vlisssides – GoF – “Gang of Four” – Standardization of Pattern – Four essential elements of Pattern • Pattern Name, Problem, Solution, Consequences
    11. 11. Design Patterns 6 March 2007 11 Software Design PatternSoftware Design Pattern  ………The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. ……… - Design Patterns: Elements of Reusable Object-Oriented Software [Addison Wesley, 1995] “ ”
    12. 12. Design Patterns 6 March 2007 12 Why Use Patterns?Why Use Patterns? • Proven – Patterns reflect the experience, knowledge and insights of developers who have successfully used these patterns in their own work. • Reusable – Patterns provide a ready-made solution that can be adapted to different problems as necessary. • Expressive – Patterns provide a common vocabulary of solutions that can express large solutions succinctly.
    13. 13. Design Patterns 6 March 2007 13 Describing Design PatternsDescribing Design Patterns Alexandrian FormAlexandrian Form • Name – meaningful name • Problem – the statement of the problem • Context – a situation giving rise to a problem • Forces – a description of relevant forces and constraints • Solution – proven solution to the problem
    14. 14. Design Patterns 6 March 2007 14 Describing Design PatternsDescribing Design Patterns Alexandrian FormAlexandrian Form • Examples – sample applications of the pattern • Resulting context (force resolution) – the state of the system after pattern has been applied • Rationale – explanation of steps or rules in the pattern • Related patterns – static and dynamic relationship • Known use – occurrence of the pattern and its application within existing system
    15. 15. Design Patterns 6 March 2007 15 Describing Design PatternsDescribing Design Patterns GoF FormatGoF Format • Pattern Name and Classification • Intent – what does pattern do / when the solution works • Also Known As – other known names of pattern (if any) • Motivation – the design problem / how class and object structures solve the problem
    16. 16. Design Patterns 6 March 2007 16 Describing Design PatternsDescribing Design Patterns GoF FormatGoF Format • Applicability – situations where pattern can be applied • Structure – a graphical representation of classes in the pattern • Participants – the classes/objects participating and their responsibilities • Collaborations – how the participants collaborate to carry out responsibilities
    17. 17. Design Patterns 6 March 2007 17 Describing Design PatternsDescribing Design Patterns GoF FormatGoF Format • Consequences – trade-offs, results, concerns • Implementation – hints, techniques • Sample Code – code fragment showing possible implementation • Known Uses – patterns found in real systems • Related Patterns – closely related patterns
    18. 18. Design Patterns 6 March 2007 18 Design Pattern SpaceDesign Pattern Space Purpose Creational Structural Behavioral Scope Class Factory Method Adapter (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
    19. 19. Design Patterns 6 March 2007 19 Design PatternDesign Pattern SingletonSingleton • Intent – Ensure a class only has one instance, and provide a global point of access to it. • Motivation – Although there can be many printers in a system, there should be only one printer spooler – There should be only one file system and one window manager
    20. 20. Design Patterns 6 March 2007 20 Design PatternDesign Pattern SingletonSingleton • Applicability – There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point – When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code
    21. 21. Design Patterns 6 March 2007 21 Design PatternDesign Pattern SingletonSingleton • Structure
    22. 22. Design Patterns 6 March 2007 22 Design PatternDesign Pattern SingletonSingleton • Participants – Singleton • Collaborations – Clients access a Singleton instance solely through Singleton’s Instance operation.
    23. 23. Design Patterns 6 March 2007 23 Design PatternDesign Pattern SingletonSingleton • Consequences – Controlled access to sole instance – Reduced name space – Permits refinement of operations and representation – Permits a variable number of instances – More flexible than class operations
    24. 24. Design Patterns 6 March 2007 24 Design PatternDesign Pattern SingletonSingleton • Implementation - Java
    25. 25. Design Patterns 6 March 2007 25 Design PatternDesign Pattern SingletonSingleton • Known Uses – The set of changes to the code (ChangeSet current) in Smalltalk-80 – The relationship between classes and metaclasses – InterViews user interface toolkit to access the unique instance of its Session and WidgetKit classes
    26. 26. Design Patterns 6 March 2007 26 Design PatternDesign Pattern SingletonSingleton • Related Patterns – Many patterns can be implemented using the Singleton pattern – Abstract Factory – Builder – Prototype
    27. 27. Design Patterns 6 March 2007 27 Architectural PatternArchitectural Pattern  An architectural pattern expresses a fundamental structure organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. - PATTERN-ORIENTED SOFTWARE ARCHITECTURE: A System of Patterns - Volume 1 [WILEY, 1996] “ ”
    28. 28. Design Patterns 6 March 2007 28 Architectural PatternArchitectural Pattern LayersLayers • Example – OSI 7-Layer Model
    29. 29. Design Patterns 6 March 2007 29 Architectural PatternArchitectural Pattern LayersLayers • Context – A large system that requires decomposition • Problem – The system we are building is divided by mix of low- and high-level issues, where high-level operations reply on the lower-level ones • Solution – Structure your system into an appropriate number of layers and place them on top of each other
    30. 30. Design Patterns 6 March 2007 30 Architectural PatternArchitectural Pattern LayersLayers • Structure – An individual layer can be described by the following CRC card: Class Collaborator Layer J  Layer J-1 Responsibility  Provides services Used by Layer J+1  Delegates subtasks to Layer J-1 Class Collaborator Layer J  Layer J-1 Responsibility  Provides services Used by Layer J+1  Delegates subtasks to Layer J-1
    31. 31. Design Patterns 6 March 2007 31 Architectural PatternArchitectural Pattern LayersLayers • Variants – Relaxed Layered System – Layering Through Inheritance • Known Uses – Virtual Machines – APIs – Information Systems (IS) – Windows NT
    32. 32. Design Patterns 6 March 2007 32 Architectural PatternArchitectural Pattern LayersLayers • Consequences – Benefits • Reuse of layers • Support for standardization • Dependencies are kept local • Exchangeability – Liabilities • Cascades of changing behavior • Lower efficiency • Unnecessary work • Difficulty of establishing the correct granularity of layers
    33. 33. Design Patterns 6 March 2007 33 Design PatternDesign Pattern RelationshipsRelationships
    34. 34. Design Patterns 6 March 2007 34 Pattern CatalogPattern Catalog  ………a collection of related patterns, where patterns are subdivided into small number of broad categories……… - PATTERN-ORIENTED SOFTWARE ARCHITECTURE: A System of Patterns - Volume 1 [WILEY, 1996] “ ”
    35. 35. Design Patterns 6 March 2007 35 Core J2EE Pattern CatalogCore J2EE Pattern Catalog
    36. 36. Design Patterns 6 March 2007 36 Pattern SystemPattern System  A pattern system for software architecture is a collection of patterns for software architecture, together with guidelines for their implementation, combination and practical use in software development. - PATTERN-ORIENTED SOFTWARE ARCHITECTURE: A System of Patterns - Volume 1 [WILEY, 1996] “ ”
    37. 37. Design Patterns 6 March 2007 37 Pattern SystemPattern System • Motivation – Individual patterns & pattern catalogs are insufficient • Benefits – Define a vocabulary for talking about software development problems – Provide a process for the orderly resolution of these problems – Help to generate & reuse software architectures
    38. 38. Design Patterns 6 March 2007 38 Pattern System – POSA2Pattern System – POSA2
    39. 39. Design Patterns 6 March 2007 39 Drawbacks of PatternsDrawbacks of Patterns • Pattern is not a Silver Bullet! • Patterns do not lead to direct code reuse. • Individual Patterns are deceptively simple. • Composition of different patterns can be very complex. • Teams may suffer from pattern overload. • Patterns are useful starting points, but they are not destinations.
    40. 40. Design Patterns 6 March 2007 40 Drawbacks of PatternsDrawbacks of Patterns • Patterns are validated by experience and discussion rather than by automated testing. • Integrating patterns into a software development process is a human- intensive activity.
    41. 41. Design Patterns 6 March 2007 41 ReferencesReferences • Douglas Schmidt and Frank Buschmann, “Patterns, Frameworks, and Middleware: Their Synergistic Relationships” Proceedings of 25th International Conference on Software Engineering, 2003. • E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. MA: Addison- Wesley, 1995. • C. Alexander, The Timeless Way of Building. New York, NY: Oxford University Press, 1979. • C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl- King, and S. Angel, A Pattern Language. New York, NY: Oxford University Press, 1977.
    42. 42. Design Patterns 6 March 2007 42 ReferencesReferences • Kent Beck and Ward Cunningham, “Using Pattern Languages for Object-Oriented Programs” Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. Available: http://c2.com/doc/oopsla87.html • J2EE Design Patterns. Available: http://java.sun.com/blueprints/patterns/index.html • Douglas C. Schmidt’s Home Page. Available: http://www.cs.wustl.edu/~schmidt/ • Design pattern – Wikipedia, the free encyclopedia. Available: http://en.wikipedia.org/wiki/Design_pattern • Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, PATTERN-ORIENTED SOFTWARE ARCHITECTURE - A System of Patterns. New York: WILEY, 1996.
    43. 43. Design Patterns 6 March 2007 43 ReferencesReferences • DEEPAK ALUR, JOHN CRUPI, DAN MALKS, CORE J2EE PATTERNS – Best Practices and Design Strategies. Prentice Hall PTR, 2001. • Martin Fowler, PATTERNS OF ENTERPRISE APPLICATION ARCHITECTURE. Addison-Wesley, 2003. • GREGOR HOHPE, BOBBY WOOLF, ENTERPRISE INTEGRATION PATTERNS – DESIGNING, BUILDING, AND DEPLOYING MESSAGING SOLUTIONS. Addison-Wesley, 2004.
    44. 44. Design Patterns 6 March 2007 44

    ×