• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content


Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Cs6201 presentation design patterns by kwangshin






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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 presentation   design patterns by kwangshin Cs6201 presentation design patterns by kwangshin Presentation Transcript

  • Design Patterns 6 March 2007 National University of Singapore School of Computing OH KWANG SHIN
  • Agenda
    • Origin of Pattern
    • Software Design Patterns
    • Why Use Patterns?
    • Describing Design Patterns
    • Architectural Pattern
    • Pattern System
    • Drawbacks of Patterns
  • Origin of Pattern
  • Origin of Pattern
  • Origin of Pattern
  • Origin 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]
    “ ”
  • Origin 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
  • Example 167 (page 783) 6ft Balcony
  • History of Software 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
  • History of Software 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
  • Software 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]
    “ ”
  • 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.
  • Describing Design Patterns Alexandrian 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
  • Describing Design Patterns Alexandrian 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
  • Describing Design Patterns GoF 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
  • Describing Design Patterns GoF 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
  • Describing Design Patterns GoF 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
  • Design Pattern Space Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor Adapter (object) Bridge Composite Decorator Façade Flyweight Proxy Abstract Factory Builder Prototype Singleton Object Interpreter Template Method Adapter (class) Factory Method Class Scope Behavioral Structural Creational Purpose
  • Design Pattern Singleton
    • 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
  • Design Pattern Singleton
    • 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
  • Design Pattern Singleton
    • Structure
  • Design Pattern Singleton
    • Participants
      • Singleton
    • Collaborations
      • Clients access a Singleton instance solely through Singleton’s Instance operation.
  • Design Pattern Singleton
    • 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
  • Design Pattern Singleton
    • Implementation - Java
  • Design Pattern Singleton
    • 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
  • Design Pattern Singleton
    • Related Patterns
      • Many patterns can be implemented using the Singleton pattern
      • Abstract Factory
      • Builder
      • Prototype
  • Architectural 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]
    “ ”
  • Architectural Pattern Layers
    • Example – OSI 7-Layer Model
  • Architectural Pattern Layers
    • 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
  • Architectural Pattern Layers
    • 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
  • Architectural Pattern Layers
    • Variants
      • Relaxed Layered System
      • Layering Through Inheritance
    • Known Uses
      • Virtual Machines
      • APIs
      • Information Systems (IS)
      • Windows NT
  • Architectural Pattern Layers
    • 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
  • Design Pattern Relationships
  • Pattern 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]
    “ ”
  • Core J2EE Pattern Catalog
  • Pattern 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]
    “ ”
  • Pattern 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
  • Pattern System – POSA2
  • Drawbacks 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.
  • Drawbacks 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.
  • References
    • Douglas Schmidt and Frank Buschmann, “ Patterns, Frameworks, and Middleware: Their Synergistic Relationships ” Proceedings of 25 th 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.
  • References
    • 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.
  • References
    • DEEPAK ALUR, JOHN CRUPI, DAN MALKS, CORE J2EE PATTERNS – Best Practices and Design Strategies. Prentice Hall PTR, 2001.