Design Patterns - PowerPoint PPT Presentation

Loading...

PPT – Design Patterns PowerPoint presentation | free to download - id: 544a88-M2Y5O



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Design Patterns

Description:

Design Patterns Satya Puvvada Objectives Gain an understanding of using design patterns to improve design and implementation Learn to develop robust, efficient and ... – PowerPoint PPT presentation

Number of Views:149
Avg rating:3.0/5.0
Slides: 104
Provided by: Shyam7
Learn more at: http://a2zdotnet.files.wordpress.com
Category:
Tags: design | patterns

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Design Patterns


1
Design Patterns
  • Satya Puvvada

2
Objectives
  • Gain an understanding of using design patterns to
    improve design and implementation
  • Learn to develop robust, efficient and reusable
    C programs using design patterns

3
Contents Day 1
  • Introduction to design patterns
  • Introduction to UML notation
  • Patterns
  • Singleton
  • Factory method
  • Abstract Factory
  • Observer
  • Strategy
  • Adapter
  • Visitor

4
Contents Day 2
  • Patterns
  • Builder
  • Bridge
  • Facade
  • Proxy
  • Composite
  • Chain of responsibility
  • Command

5
Contents Day 3
  • Patterns
  • Flyweight
  • Memento
  • State
  • Decorator
  • Prototype
  • Mediator
  • Case Study
  • References and conclusions

6
Why design patterns
  • Developing software is hard
  • Designing reusable software is more challenging
  • finding good objects and abstractions
  • flexibility, modularity, elegance reuse
  • takes time for them to emerge, trial and error
  • Successful designs do exist
  • exhibit recurring class and object structures

7
Why OO Design Patterns
  • Effective for teaching OOD
  • OOP is a new Art form
  • People have only had 20 years experience with
    OOP
  • Architecture and painting have been around for
    thousands of years.
  • Effective method of transferring skill and
    experience
  • new OO programmers can be overwhelmed by the
    options

8
History of Design Patterns
  • Christopher Alexander - an architect
  • The Timeless Way of Building, 1979
  • A Pattern Language, 1977
  • Pattern - A solution to a problem in a context
  • Purposes
  • effective reuse
  • dissemination of solutions

9
History in OOP
  • 1987 workshop at OOPSLA Beck and Ward
  • 1993 The Hillside Group - Beck, Ward, Coplien,
    Booch, Kerth, Johnson
  • 1994 Pattern Languages of Programming (PLoP)
    Conference
  • 1995 Design Patterns Elements of Reusable OO
    software - Gamma, Helm, Johnson, Vlissides (Gang
    of Four)

10
Definitions / Terminology
  • Pattern Language - a term from Christopher
    Alexander, not a software language but a group of
    patterns used to construct a whole
  • Pattern - many definitions see FAQ, lets try this
    one Patterns represent distilled experience
    which, through their assimilation, convey expert
    insight and knowledge to inexpert developers.
    - Brad Appleton

11
What is a design pattern
  • a standard solution to a common programming
    problem
  • a technique for making code more flexible by
    making it meet certain criteria
  • a design or implementation structure that
    achieves a particular purpose
  • a high-level programming idiom
  • shorthand for describing certain aspects of
    program organization
  • connections among program components
  • the shape of a heap snapshot or object model

12
What is a design pattern
  • Describes recurring design structure
  • names, abstracts from concrete designs
  • identifies classes, collaborations,
    responsibilities
  • applicability, trade-offs, consequences

13
What is a design pattern
  • Design patterns represent solutions to problems
    that arise when developing software within a
    particular context
  • Patterns problem/solution pairs in a
    context
  • Patterns capture the static and dynamic
    structure and collaboration among key
    participants in software designs
  • Especially good for describing how and why to
    resolve nonfunctional issues
  • Patterns facilitate reuse of successful software
    architectures and designs.

14
Applications
  • Wide variety of application domains drawing
    editors, banking, CAD, CAE, cellular network
    management, telecomm switches, program
    visualization
  • Wide variety of technical areas user interface,
    communications, persistent objects, O/S kernels,
    distributed systems

15
Definition
  • 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 in the same way twice
  • Christopher Alexander, A Pattern Language,
    1977

16
Design Patterns
  • A pattern has 4 essential elements
  • Pattern name
  • Problem
  • Solution
  • Consequences

17
How a Pattern is Defined(GoF form)
  • Name - good name
  • Intent- what does it do
  • Also Known As
  • Motivation - a scenario
  • Applicability - when to use
  • Structure- UML
  • Participants - classes
  • Collaborations - how they work together
  • Consequences - trade offs
  • Implementation- hints on implementation
  • Sample Code
  • Known Uses
  • Related Patterns

18
Classes of Design Patterns
  • Creational patterns
  • Deal with initializing and configuring classes
    and objects
  • Structural patterns
  • Deal with decoupling interface and implementation
    of classes and objects
  • Composition of classes or objects
  • Behavioral patterns
  • Deal with dynamic interactions among societies of
    classes and objects
  • How they distribute responsibility

19
UML Notation
20
Class symbol
1. Name compartment 2. Attribute compartment 3.
Operation compartment 4. Class name 5.
Properties 6. Stereotype
21
Class diagram - associations
  • Used to associate classes
  • Symbol used is a line with some adornments
  • Each association is given a name that matches the
    association

22
Class diagram - multiplicity
  • A number of objects of each class may be
    associated
  • Customer may open many accounts, order may
    contain many items
  • Asterisk () when used alone means zero or more,
    no lower or upper limit
  • Asterisk () when used in a range (1..) means no
    upper limit
  • Values separated by two periods (..) means a
    range.
  • Values separated by commas means an enumerated
    list of values.

23
Class diagram - multiplicity
24
Class diagram Roles and constraints
When an association cannot be give a name a role
can be assigned to either ends of the association
25
Class diagram Roles and constraints
1. Role Must have a name or roles or both 2.
Association name Must have a name or roles or
both 3. Role Must have a name or roles or
both 4. Class 5. Constraint Optional 6.
Multiplicity Required 7. Association 8.
Multiplicity Required 9. Class
26
Class diagram Reflexive associations
1. Objects in the same class is associated
27
Class diagram Qualified associations
  • Used to reduce multiplicity
  • Used like a database index
  • Can be used when both sides of an association has
    0..

28
Class diagram Association classes
1. A class that is used to give information about
an association
29
Class diagram Aggregation and composition
  • Special type of association
  • Used to show that a class is made up of other
    classes

30
Class diagram composition
  • Similar to aggregation
  • It is used when the lifespan of the parts depend
    on the lifespan of the aggregate

31
Class diagram generalization
Same as inheritance No multiplicity shown Links
classes together where each class consists a
subset of the element that is to be finally
defined
32
Class diagram delegation
Can be used to reduce generalization Makes one
class a part of another class using aggregation
33
Sequence diagrams
1. Object lifeline 2. Message/Stimulus 3.
Iteration 4. Self-reference 5. Return 6.
Anonymous object 7. Object name 8. Sequence
number 9. Condition 10. Basic comment
34
Sequence diagrams
1. Activation The start of the vertical
rectangle, the activation bar 2. Deactivation
The end of the vertical rectangle, the activation
bar 3. Timeout event Typically signified by a
full arrowhead with a small clock face or circle
on the line 4. Asynchronous event Typically
signified by stick arrowhead 5. Object
termination symbolized by an X 6. Synchronous
message Typically signified with a solid line
and filled arrowhead 7. Return Typically
signified with a dashed line and line stick
arrowhead
35
Collaboration diagrams
36
Collaboration diagram - observer
37
Patterns
38
Singleton Pattern - Creational
  • The Singleton pattern ensures that a class has
    only one instance and provides a global point of
    access to it.
  • Examples
  • There can be many printers in a system but there
    should only be one printer spooler.
  • There should be only one instance of a
    WindowManager (GrainWindowingSystem).
  • There should be only one instance of a
    filesystem.

39
Singleton Pattern
  • How do we ensure that a class has only one
    instance and that the instance is easily
    accessible?
  • A global variable makes an object accessible, but
    does not keep you from instantiating multiple
    objects.
  • A better solution is to make the class itself
    responsible for keeping track of its sole
    instance. The class ensures that no other
    instance can be created (by intercepting requests
    to create new objects) and it provides a way to
    access the instance.

40
Singleton Pattern
  • Use the Singleton pattern when
  • 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.

41
Singleton Structure
Singleton static Instance() SingletonOpera
tion() GetSingletonData() static
uniqueinstance singletonData
return uniqueinstance
42
Singleton Particpants
  • Singleton
  • Defines an Instance operation that lets clients
    access its unique instance. Instance is a class
    operation (static member function in C)
  • May be responsible for creating its own unique
    instance
  • Client
  • Acesses a Singleton instance solely through
    Singletons Instance operation.

43
Singleton Consequences
  • Controlled access to sole instance
  • Because the Singleton class encapsulates its sole
    instance, it can have strict control over how and
    when clients access it.
  • Reduced name space
  • The Singleton pattern is an improvement over
    global variables. It avoids polluting the name
    space with global variables that store sole
    instances.

44
Singleton Consequences
  • Permits refinement of operations and
    representations
  • The Singleton class may be subclassed and it is
    easy to configure an application with an instance
    of this extended class at run-time.

45
Singleton Implementation
  • Ensuring a unique instance
  • The Singleton pattern makes the sole instance a
    normal instance of a class, but that class is
    written so that only one instance can ever be
    created. A common way to do this is to hide the
    operation that creates the instance behind a
    static class operation that guarantees that only
    one instance is created.

46
Singleton Sample Code
  • class Singleton
  • public
  • static Singleton Instance()
  • // clients access the Singleton exclusively
    through
  • // the Instance() member function
  • protected
  • Singleton()
  • // the constructor is protected, such that a
    client
  • // which tries to instantiate a Singleton
    object gets
  • // a compiler error
  • private
  • static Singleton instance_

47
Singleton Sample Code
  • Singleton Singletoninstance_ 0
  • // initialize static member data of class
    Singleton
  • Singleton SingletonInstance()
  • if (instance_ 0) // if not created yet
  • instance_ new Singleton // create once
  • return instance_

48
Pattern Factory Method
  • Synopsis Define an interface for creating an
    object, but let subclasses decide which class to
    instantiate.
  • Factory Method lets a class defer instantiation
    to subclasses
  • Context Example is that of a GUI framework.
    The generic Application class will have a method
    createDocument to create a generic document. A
    specific use of the framework for, say,
    word-processing GUI would subclass the generic
    Application class and override the
    createDocument method to generate word-processing
    documents.

49
Pattern Factory Method
  • Forces Use the Factory Method pattern when
  • a class cant anticipate the class of objects
    it must create
  • a class wants its subclasses to specify the
    objects it creates
  • the set of classes to be generated may be
    dynamic

50
Pattern Factory Method
  • Solution Use a factory method to create the
    instances
  • Product (e.g. Document) defines the interface
    of objects the factory method creates
  • ConcreteProduct (e.g. MyDocument) implements
    the Product interface
  • Creator (e.g. Application) declares the
    factory method which returns an object of type
    Product (possibly with a default implementation)
    may call the factory method to create a Produce
    object
  • ConcreteCreator (e.g. MyApplication)
    overrides the factory method to return an
    instance of ConcreteProduct

51
Pattern Factory Method
52
Pattern Factory Method
  • Factory method class creational
  • Consequences
  • It eliminates the need to bind
    application-specific classes into your code. The
    code only deals with the Product interface and
    therefore can work with any user-defined
    ConcreteProduct classes.
  • A client will have to subclass the Creator
    class just to create a particular ConcreteProduct
    instance.

53
Pattern Factory Method
  • Provides hooks for subclasses to provide
    extended versions of objects
  • Connects parallel class hierarchies, e.g.
    Application Document vs MyApplication
    MyDocument
  • The set of product classes that can be
    instantiated may change dynamically

54
Factory Method
  • Applicability Use when
  • a class cannot anticipate the class of objects it
    must create
  • a class wants its subclasses to specify the
    objects it creates
  • classes delegate responsibility to one of several
    helper subclasses, and you want to localize the
    knowledge of which helper subclass to delegate.

55
Factory method
  • Source code

56
AbstractFactory
  • Abstract factory object creational
  • Synopsis Provides a way to create instances of
    abstract
  • matched set of concrete subclasses
  • Context Consider building a GUI framework
    which should work with multiple windowing systems
    (e.g. Windows, Motif, MacOS) and should provide
    consistent look-and-feel.
  • Forces Use the Abstract Factory pattern when
  • a system should be independent of how its
    products are
  • created, composed and represented
  • a system should be configured with one of
    multiple families of products

57
AbstractFactory
  • a family of related products is designed to be
    used together, and you need to enforce this
    constraint
  • you want to provide a class library of
    products, and only reveal their interfaces, not
    their implementations

58
AbstractFactory
  • Solution Define an abstract factory class
    which has methods to generate the different kinds
    of products. (For a windowing system this could
    generate matched buttons, scroll bars, fields).
  • The abstract factory is subclassed for a
    particular concrete set of products
  • AbstractFactory declares an interface for
    operations that create abstract product objects
  • ConcreteFactory implements the operations to
    create
  • concrete product objects
  • AbstractProduct declares an interface for a
    type of product object
  • ConcreteProduct implement the AbstractProduct
    interface

59
AbstractFactory
  • Client uses only the interfaces declared by
    AbstractFactory
  • and AbstractProduct classes

60
AbstractFactory
61
AbstractFactory
  • Abstract factory object creational
  • Consequences
  • It isolates concrete classes
  • clients are isolated from implementation
    classes
  • clients manipulate instances through their
    abstract interfaces
  • It makes exchanging product families easy
  • It promotes consistency among products

62
AbstractFactory
  • Supporting new kinds of product is difficult
  • the AbstractFactory interface fixes the set of
    products that can be created
  • extending the AbstractFactory interface will
    involve changing all of the subclasses
  • The hierarchy of products is independent of the
    client

63
AbstractFactory
  • Supporting new kinds of product is difficult
  • the AbstractFactory interface fixes the set of
    products that can be created
  • extending the AbstractFactory interface will
    involve changing all of the subclasses
  • The hierarchy of products is independent of the
    client

64
AbstractFactory
  • Source code

65
Observer - Behavioral
  • One-to-many dependency between objects change of
    one object will automatically notify observers

66
Observer Applicability
  • A change to one object requires changing an
    unknown set of others
  • Object should be able to notify others that may
    not be known at the beginning

67
Observer Structure
68
Observer Consequences
  • Abstract coupling between subject and observer
  • Support for broadcast communication
  • Hard to maintain

69
Observer Consequences
  • Loose coupling in communication
  • Observers decide what happens
  • Dynamic change of communication
  • Anonymous communication
  • Multi-cast and broadcast communication

70
Observer
  • Source code

71
Strategy - Behavioural
  • Consider a system that needs to break a stream of
    text into lines. There are many algorithms for
    doing this hardwiring a particular algorithm
    may be undesirable
  • clients will be more complex if they include
    the algorithm different algorithms will be
    appropriate at different times or in different
    contexts
  • it is difficult to add new algorithms
  • The solution is to define classes which
    encapsulate different line-breaking algorithms
  • the so-called Strategy pattern

72
Strategy
  • Synopsis Define a family of algorithms,
    encapsulate each one,and make them
    interchangeable. Strategy lets the algorithm
  • vary independently from clients that use it
  • Context In a document editor you may want to
    vary the choice of line-breaking strategies,
    possibly on-the-fly
  • Forces Use the Strategy pattern when
  • many related classes differ only in their
    behavior, in which case the Strategy provides a
    way of configuring a class with one of many
    behaviors

73
Strategy
  • you need different variants of an algorithm
  • an algorithm uses data that clients shouldnt
    know about
  • Strategy avoids exposing complex,
    algorithm-specific data
  • structures
  • a class defines multiple alternative behaviors

74
Strategy
  • Solution Encapsulate the algorithm in an object
  • Strategy (e.g. Compositor) declares an
    interface common to all supported algorithms.
  • Context uses this interface to call the
    algorithms defined by a ConcreteStrategy
  • ConcreteStrategy (e.g. SimpleCompositor)
    implements the algorithm using the Strategy
    interface
  • Context (e.g. Composition) is configured with
    a ConcreteStrategy object, and may define an
    interface that lets Strategy access its data.

75
Strategy
76
Strategy
  • Consequences The Strategy pattern has the
    following benefits and drawbacks
  • families of related algorithms can be defined
    using a class hierarchy, thus allowing common
    functionality of the algorithms to be factored
    out
  • an alternative to subclassing for providing a
    variety of algorithms or behaviours. Subclassing
    for modifying behaviour hard-wires the behaviour
    into Context. Further, subclassing does not
    support dynamic modification of the algorithm
  • Strategies can eliminate conditional statements
    used to select the particular algorithm

77
Strategy
  • Strategies provide a choice of implementations,
    depending for example, on different time and
    space tradeoffs

78
Adapter Pattern - Structural
  • Convert the interface of a class into another
    interface clients expect. Adapter lets classes
    work together that couldn't otherwise because of
    incompatible interfaces.

79
The Adapter (Wrapper) Pattern
  • Context you are building an inheritance
    hierarchy and want to incorporate it into an
    existing class
  • The reused class is also often already part of
    its own inheritance hierarchy
  • Problem how to obtain the power of polymorphism
    when reusing a class whose methods have the same
    function, but NOT the same signature as the other
    methods in the hierarchy?
  • Forces you do not have access to multiple
    inheritance or you do not want to use it

80
More on Adapter
  • In fact, there are two variants of the adapter
    pattern
  • Class adapter, which uses multiple inheritance to
    adapt one interface to another
  • Object adapter, which uses single inheritance and
    delegation

81
Adapter pattern
  • Delegation used to bind an Adapter and an Adaptee
  • Interface inheritance used to specify the
    interface of the Adapter class

82
Adapter Example
83
Adapter Structure
84
Code sample - Inheritance
class OldSquarePeg public void
squarePegOperation() do something
class RoundPeg public void virtual
roundPegOperation 0
85
Code sample
class PegAdapter private OldSquarePeg,
public RoundPeg public void
virtual roundPegOperation() add some
corners squarePegOperation()

86
Code sample
void clientMethod() RoundPeg aPeg new
PegAdapter() aPeg-gtroundPegOperation()

87
Code sample - Composition

class OldSquarePeg public void
squarePegOperation() do something
class RoundPeg public void virtual
roundPegOperation 0
88
Code sample - Composition
class PegAdapter public RoundPeg
private OldSquarePeg square public
PegAdapter() square new OldSquarePeg
void virtual roundPegOperation()
add some corners
square-gtsquarePegOperation()


89
Visitor Pattern
  • Parse Trees
  • If an expression has a correct syntax according
    to a grammar then we can make a parse tree for
    it.

90
Visitor Pattern
  • Visitor pattern works for a tree data structure
    with many different types of nodes.
  • Compilers and other programs (ex pretty
    printers) do lots of operations by traversing the
    parse tree visiting every node.

91
Visitor Pattern - Behavioural
  • Represent an operation to be performed on the
    elements of an object structure. Visitor lets you
    define a new operation without changing the
    classes of the elements on which it operates.

92
Visitor example
93
Visitor example
94
Visitor applicability
  • many distinct and unrelated operations need to be
    performed on objects in an object structure, and
    you want to avoid "polluting" their classes with
    these operations

95
Visitor Structure
96
Visitor Structure
97
Pros and Cons
  • Pros
  • Visitor makes adding new operations easy
  • Visitor gathers related operations and separates
    unrelated ones
  • Ability to visit across hierarchies
  • Ability to accumulate states
  • Cons
  • Adding concrete element classes is hard
  • slots encapsulation

98
Visitor Consequences
  • Visitor makes adding new operations easy
  • A visitor gathers related operations and
    separates unrelated ones
  • Adding new Concrete Element classes is hard
  • Visiting across class hierarchies
  • Accumulating state.
  • sloting encapsulation

99
Code sample
struct Transform // forward declaration struct
Geometry // forward declaration struct Visitor
virtual void visit_transform( Transform )
0 virtual void visit_geometry ( Geometry
) 0 virtual Visitor()
100
Code sample
struct Render public Visitor virtual void
visit_transform( Transform ) // render
Transform virtual void visit_geometry ( Geometry
) // render Geometry struct Optimize
public Visitor virtual void visit_transform(
Transform ) // optimize Transform virtual
void visit_geometry ( Geometry ) // optimize
Geometry
101
Code sample
struct Node virtual void accept( Visitor )
0 virtual Node() struct Transform
public Node virtual void accept( Visitor v)
v-gtvisit_transform( this)
102
Code sample
struct Geometry public Node virtual void
accept( Visitor v) v-gtvisit_geometry( this)
Main() Struct geometry mygeom // create
geometry node Struct Render myrender Mygeom-gtacc
ept(myrender)
103
(No Transcript)
About PowerShow.com