Design Patterns - PowerPoint PPT Presentation

About This Presentation
Title:

Design Patterns

Description:

PowerPoint Presentation ... Design Patterns – PowerPoint PPT presentation

Number of Views:170
Avg rating:3.0/5.0
Slides: 124
Provided by: monta156
Category:

less

Transcript and Presenter's Notes

Title: Design Patterns


1
Design Patterns
2
Overview
  • The need to manage complexity
  • Place of data structures and algorithms
  • Class diagrams in UML
  • Beyond objects to patterns
  • Example pattern
  • Reference Gamma et.al. chapter 1
  • http//hillside.net/patterns
  • http//www.cs.wustl.edu/schmidt/patterns-info.htm
    l

3
Managing software complexity
  • There is a desperate need to be able to generate
    complex, reliable software.
  • increasing functionality
  • increasing machine capacity
  • decreasing software quality
  • Examples of poor software quality?

4
How can you manage complexity?
  • Software? Filing system? Building a house?
  • structure?
  • components?
  • techniques?
  • processes?
  • Lets concentrate on structure and see how we can
    manage complexity there.

5
We tend to learn programming bottom-up
  • Start with simple values and variables
  • integers, booleans, reals
  • assignment, conditional statements, loops
  • Work up to data structures
  • sets of values in relationship
  • commonly occurring abstractions
  • arrays, linear lists, stacks, queues
  • trees, graphs
  • Examine interplay between data structures and
    algorithms
  • choice of data structure affects efficiency of
    algorithm

6
Data structures and classes
  • In object-oriented terms, data structures and
    associated algorithms are usually described by
    abstract data types and encapsulated in objects
    or classes.
  • e.g. List, Tree, Graph, Trie, etc.
  • Get the data structures right and everything
    else will follow
  • How do you get the data structures right?
  • How do you get the classes right?
  • How do you get a broader view of a system?
    Another level of abstraction?
  • consider classes as components
  • What are good ways of combining classes?
  • combine classes to give design patterns

7
Abstraction given by class diagrams
  • Can represent classes as nodes in a graph, with
    edges giving the relationships between the
    classes
  • Nodes can indicate state, behaviour (, identity)
    of classes
  • State attributes associated such an object (the
    instance variables).
  • Behaviour operations applicable to such an
    object (the instance methods).
  • Identity unique value that differentiates one
    object from another (usually implicit)
  • Examples
  • Bank account
  • University professor

8
Nodes can indicate more detail
  • Note included attributes do not include
    references to other objects include these by
    associations
  • Types
  • e.g. balance real
  • e.g. deposit(amount real) void
  • Access control
  • public balance real
  • protected balance real
  • private balance real

9
Nodes can indicate more detail
  • Identify class variables and methods by
    underlining
  • Annotate special kinds of components with
    stereotypes
  • e.g. constructor BankAccount()
  • e.g. interface Graph

10
Class relationships
  • Classes are related to other classes
  • a GraphBase class may implement a Graph interface
  • a GraphImp class may use NodeImp and EdgeImp
    classes
  • a SavingsAccount class may extend a BankAccount
    class
  • These relationships are drawn as arcs in the
    class diagram

11
Edge annotations
  • (Central) label indicates significance of
    association
  • context determines which way to read the
    association
  • e.g. an Edge joins two Nodes
  • End-point labels indicate roles
  • implications for implementation
  • Multiplicity indicates number of participants
  • e.g. optional 0..1
  • e.g. zero or more 0..
  • e.g. one or more 1..

Edge
Node
1
2
edge
node
label setLabel(lbl) getLabel()
label setLabel(lbl) getLabel()
joins
12
Edge annotations
  • Arrow heads indicate navigation direction
  • bidirectional navigation
  • unidirectional navigation
  • implications for implementation
  • Style of arrow
  • e.g. inherits A inherits B
  • e.g. implements A implements B
  • e.g. aggregates A aggregates B
  • e.g. composite A is a composite of B

13
Aggregates vs composites
  • Aggregates and composites indicate a special
    association
  • their use is optional
  • Aggregates indicate a part-whole relationship
  • Composites indicate a part-whole relationship
    where the whole strongly owns the parts
  • Copy/delete the whole ? copy/delete the parts
  • E.g. student enrolled in a degree no
    aggregation
  • E.g. degree includes compulsory course
    aggregation
  • not composite courses may belong to multiple
    degree
  • E.g. building consists of 4 floors composite
  • floors cannot belong to more than one building

14
Specializing BankAccount
  • Inheritance and software reuse
  • A bank account with an overdraft facility
  • A tenured vs contract University teacher
  • Reuse state and behaviour
  • Fundamental to the provision of
  • Graphical User Interfaces.

15
Relating BankAccount and Custome
  • Objects can use other objects to accomplish their
    tasks
  • A bank account could have an associated customer
  • The customer object could be notified about
    overdrafts
  • Reuse state and behaviour
  • Maintains encapsulation

16
Inheritance vs Composition
  • Inheritance has been promoted as the reuse
    mechanism
  • Experience shows that composition is a cleaner
    mechanism
  • Inheritance hierarchies can become overly complex
  • Inheritance breaks encapsulation (at least
    partially)
  • Inheritance is a static compile-time mechanism,
    while composition can be a dynamic run-time
    mechanism (added flexibility may be good or bad)
  • Implementation of parent will affect that of the
    child

17
Unified Modeling Language (UML)
  • Previous class diagram notation is part of the
    Unified Modelling Language (UML)
  • arose out of other notations OMT, Booch,
    Jacobsen
  • UML also addresses other models
  • Use Case diagrams for capturing external
    interactions
  • State diagrams for capturing the internal class
    activity
  • Interaction diagrams for capturing interaction
    between classes
  • Sequence diagrams for capturing more detailed
    interaction between classes
  • Deployment diagrams for relating software to
    available hardware
  • ...

18
Beyond objects
  • Object-oriented software construction is not
    enough
  • Typical systems have a large number of
    objects/classes
  • Relationships between classes can be very complex
  • Becomes unmanageable
  • Consider commonly occurring sets of classes
    patterns
  • E.g. contract for house sale speaks in terms of
    Vendors, Purchasers, Premises, Chattels, etc.
  • A set of objects is required for such a contract

19
Beyond patterns
  • Patterns may not be enough to structure complex
    software
  • You may require a higher level view of the system
  • This leads to the topic of software architecture
    ...

20
Example the Adapter (class) pattern
  • Consider wanting to use a prebuilt component
    which does not match the interface you assumed
  • very common when you try to reuse software

21
Example the Adapter (class) example
  • Consider supplying a bank account (as above) in
    terms of an account which has a single method for
    changes

22
Example the Adapter (object) pattern
  • Consider wanting to use a prebuilt component
    which does not match the interface you assumed
  • Adaptee is used, not inherited

23
Example the Adapter (object) pattern
  • Consider needing a bank account (as above) in
    terms of an account which has a single method for
    changes.

24
Where next?
  • Describing and classifying patterns
  • Creational patterns for more flexible object
    creation
  • Reference Gamma et.al. chapters 3-4
  • http//hillside.net/patterns
  • http//www.cs.wustl.edu/schmidt/patterns-info.htm
    l

25
Reminder
  • Patterns capture solutions to commonly occurring
    problems
  • Many problems arise in the context of GUIs
  • Authors need to identify 3 distinct uses/contexts
    before classifying the solution as a pattern
  • Patterns consist of a number of classes which
    interact in a certain way (to solve the problem)
  • Patterns may or may not be applicable in a given
    context
  • Many patterns introduce extra levels of
    indirection
  • Most problems in Computer Science can be solved
    with an extra level of indirection

26
Description of patterns
  • Name succinct indication of patterns purpose
  • Synopsis short description of the pattern (for
    experienced users)
  • Context problem description example problem
  • Forces considerations leading to the solution
  • Solution describes the general-purpose solution
  • Consequences trade-offs and results
  • Implementation pitfalls, hints, techniques
  • Sample code
  • Related patterns similar sorts of situations

27
Example description Adapter pattern
  • Name Adapter Class, Object Structural
  • Synopsis implements an interface known to the
    clients via a class which is not known to the
    clients
  • Context the class interfaces derived from the
    design of a system may not match the class
    interface available in a reusable library. E.g.
    BankAccount class with two methods
    deposit(amount) and withdraw(amount) to be
    adapted to a class Account which has a single
    method change(amount) which accepts positive and
    negative amounts.
  • Forces
  • You want to use an existing class, and its
    interface does not match the one you need
  • You do not have the option of changing the
    interface of the existing class maybe the
    source isnt available, or the class is part of a
    reusable library

28
Example description Adapter pattern
  • Solution A class adapter uses multiple
    inheritance to adapt one interface to another. An
    object adapter relies on object composition
  • Target defines the domain-specific interface that
    Client uses
  • Client collaborates with objects conforming to
    the Target interface
  • Adaptee defines an existing interface that needs
    adapting
  • Adapter adapts the interface of Adaptee to the
    Target interface

29
Example the Adapter (class) pattern
  • Reuse a prebuilt class which does not match the
    interface you assumed
  • very common when you try to reuse software

30
Java-line code for Adapter class pattern
  • abstract class Target // Maybe an interface
  • public abstract ResultType request()
  • class Adaptee // An existing class
  • public ResultType req()

31
Java-line code for Adapter class pattern
  • class Adaptor extends Target, Adaptee
  • public ResultType request()
  • return req() // Use Adaptee version
  • Note that Java does not support multiple
    inheritance
  • the above would be possible in C, Eiffel
  • the above would be possible if Target were an
    interface, in which case Adaptor would inherit
    Adaptee and implement Target

32
The Adapter (object) pattern
  • Consider wanting to use a prebuilt component
    which does not match the interface you assumed

33
Java-like code for Adapter object pattern
  • Target and Adaptee classes as before
  • class Adaptor extends Target // Does not inherit
    Adaptee
  • Adaptee adpt new Adaptee()
  • public ResultType request()
  • return adpt.req() // Use Adaptee version
  • Note that this works directly in Java

34
Example description Adapter pattern
  • Consequences Class and object adapters have
    different trade-offs. A class adapter
  • adapts Adaptee to Target by committing to a
    concrete Adapter class. As a consequence, a class
    adapter wont work when we want to adapt a class
    and all its subclasses.
  • lets Adapter override some of Adaptees
    behaviour, since Adapter is a subclass of Adaptee
  • introduces only one object, and no additional
    pointer indirection is needed to get to the
    Adaptee.

35
Example description Adapter pattern
  • Consequences Class and object adapters have
    different trade-offs. An object adapter
  • lets a single Adapter work with many Adaptees,
    i.e. the Adaptee itself and all of its subclasses
    (if any). The Adapter can also add functionality
    to all Adaptees at once.
  • makes it harder to override Adaptee behaviour. It
    will require subclassing Adaptee and making
    Adapter refer to the subclass rather than the
    Adaptee itself.
  • Related patterns Facade, Proxy, Strategy

36
Classification of patterns
  • There are two basic dimensions of classification
  • Scope
  • application primarily to classes or objects?
  • Purpose
  • creational for creating (and deleting) objects
  • structural for composing classes or objects
  • behavioural interaction of classes or objects

37
Example classification Adapter pattern
  • Adapter is of scope class or object
  • Adapter is of purpose structural

38
Creational patterns
  • These patterns provide alternatives to creation
    of objects by using the new function which
  • fixes the class of object being created
  • i.e. lacks flexibility / configurability
  • is independent of other calls to new
  • i.e. does not relate creation of different kinds
    of objects
  • Suppose we have a situation where a number of
    related objects (or products) need to be created
  • e.g. set of graphical components with similar
    look-and-feel
  • e.g. set of bank accounts with matching audit
    provisions
  • A common problem!

39
Abstract factory object creational
  • Synopsis Provides a way to create instances of
    abstract classes from a 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
  • 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

40
Abstract factory object creational
  • 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
  • Client uses only the interfaces declared by
    AbstractFactory and AbstractProduct classes

41
Abstract factory object creational
42
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
  • 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

43
Lexi consistent look-and-feel
44
Java code for Abstract Factory pattern
  • abstract class Product1 // Some kind of object
  • abstract class Product2 // Another kind of
    object
  • // - related to Product1
  • abstract class AbstractFactory
  • public abstract Product1 createProduct1()
  • public abstract Product2 createProduct2()

45
Java code for Abstract Factory pattern
  • class version1Product1 extends Product1 //
    Specific kind
  • // of Product1
  • class version1Product2 extends Product2 //
    Specific kind
  • // of Product2
  • class version2Product1 extends Product1 //
    Another kind
  • // of Product1
  • class version2Product2 extends Product2 //
    Another kind
  • // of Product2

46
Java code for Abstract Factory pattern
  • class version1Factory extends AbstractFactory
  • // Factory for version1 products
  • public Product1 createProduct1()
  • return new version1Product1()
  • public Product2 createProduct2()
  • return new version1Product1()
  • Similarly for a class version2Factory

47
Java code for Abstract Factory pattern
  • class client
  • static void main()
  • AbstractFactory fact new version1Factory()
  • ... fact.createProduct1() // version1 products
  • ... fact.createProduct2()
  • With the one line fact new version2Factory(),
    you would end up with version2 products

48
Creational patterns
  • In the abstract factory the family of related
    products was independent of the client(s)
  • A GUI framework needs to generate related
    products, but the products depend on the
    structure of the client classes
  • e.g. a word-processor application needs to
    generate word-processor documents, and
    word-processor documents need to be displayed in
    word-processor views
  • Solution is to define methods in the (generic)
    client classes to create (generic) objects
  • then override these methods in a specific
    application

49
Sample generic application and documents
50
Factory method class creational
  • 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.
  • 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

51
Factory method class creational
  • 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

52
Factory method class creational
53
Factory method class creational
  • Consequences
  • It eliminates the need to bind application-specifi
    c 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.
  • 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
Structural patterns
  • Reference Gamma et al. Chapter 4.
  • These patterns allow you to achieve different
    relationships between classes or objects
  • Adapter is a structural pattern
  • Consider a situation where you have some
    recursive composition of objects
  • e.g. consider a document formatting program that
    formats characters into lines, lines into
    columns, columns into pages
  • suppose that columns can contain frames which can
    contain columns
  • the recursive structure can get rather
    complicated

55
Structural patterns
56
Composite object structural
  • Synopsis Allows you to build complex objects by
    recursively composing similar objects in a
    treelike manner, representing whole-part
    hierarchies
  • Context In a document-formatting program (such
    as described previously), the complex inclusion
    relationships can lead to complex code. This is
    made worse if you try to handle primitive and
    container objects differently. The key to the
    pattern is to define an abstract class which
    represents both primitive and composite
    components
  • Forces
  • you have a complex object that needs to be
    decomposed into a part-whole hierarchy
  • you want to minimise the complexity of the
    part-whole hierarchy by minimising the number of
    different kinds of child objects

57
Composite- object structural
  • Solution Provide an abstract superclass for all
    objects in the hierarchy and an abstract
    superclass for all composites in the hierarchy
  • AbstractComponent the common superclass for all
    objects in the hierarchy
  • AbstractComposite the common superclass for all
    composite objects in the hierarchy. It inherits
    from AbstractComponent and has additional methods
    to add and remove components
  • ConcreteComponent specific component in the
    hierarchy
  • ConcreteComposite specific composite in the
    hierarchy

58
Composite object structural
59
Composite object structural
  • Consequences
  • The tree-like composite object can be treated as
    consisting of AbstractComponents (whether they
    are simple or composite)
  • Clients of AbstractComponent can ignore whether
    it is actually a composite or not
  • An operation performed on an AbstractComposite
    treated as an AbstractComponent can be delegated
    to the component objects
  • Any AbstractComponent object can be a child of an
    AbstractComposite. More restrictive policies can
    be enforced.
  • Related patterns Chain of responsibility

60
Composite object structural
61
Glyph interface for Lexi
  • All graphics, whether simple or composite, will
    have a common interface of a Glyph
  • interface Glyph
  • void Draw(Window) // to display itself
  • Rect Bounds() // return the bounding rectangle
  • Boolean Intersects(Point) // determine if the
    point is in the
  • // bounding rectangle (and the glyph
  • // needs to respond to some event)
  • void Insert(Glyph, int) // add a component
    glyph
  • void Remove(Glyph) // remove a glyph
  • Glyph Child(int) // return a component glyph
  • Glyph Parent() // return the parent glyph

62
Structural patterns
  • Consider a situation where you want to control
    access to an object
  • e.g. a distributed system where the application
    needs to interact with an object but it should
    not need to know whether the object is local or
    remote
  • e.g. a word processor where you do not wish to
    open and display a (large) image unless it is
    required

63
Example- text document with large images
64
Proxy object structural
  • Synopsis Provide a surrogate or placeholder for
    another object to control access to it
  • Context A proxy object receives method calls
    from clients on behalf of another object. The
    proxy object does not provide the services
    directly but calls the methods of the object.
    Proxy is applicable whenever there is a need for
    a more versatile or sophisticated reference to an
    object than a simple pointer, such as
  • a remote proxy provides a local representative
    for an object in a different address space
  • a virtual proxy creates expensive objects on
    demand
  • a protection proxy controls access to the
    original object
  • a smart reference is a replacement for a bare
    pointer that performs additional actions when an
    object is accessed

65
Proxy object structural
  • Forces
  • the service-providing object cannot provide the
    service at a convenient time and place
  • gaining visibility to an object is non-trivial
    and you want to hide the complexity
  • you want to control access to the
    service-providing object

66
Proxy object structural
  • Solution Proxy forwards requests to RealSubject
    when appropriate, depending on the kind of proxy
  • Subject (e.g. Graphic) defines the common
    interface for RealSubject and Proxy so that Proxy
    can be used anywhere that RealSubject is expected
  • RealSubject (e.g. Image) defines the real
    object that the proxy represents
  • Proxy (e.g. ImageProxy) maintains a reference
    that lets the proxy access the real subject
    provides an interface identical to Subjects so
    that a proxy can be substituted for the real
    subject controls access to the real subject

67
Proxy object structural
68
Proxt object structural
  • Consequences
  • The additional level of indirection in accessing
    an object can have many uses
  • a remote proxy can hide the fact that an object
    resides in a different address space
  • a virtual proxy can perform optimisations such as
    creating an object on demand
  • protection proxies and smart references allow
    additional housekeeping tasks when an object is
    accessed
  • A Proxy can also be used to defer duplication of
    a (large) object until the duplicate is actually
    changed (and the copy needs to be generated)
  • Related patterns Facade, Decorator

69
Structural patterns
  • Consider a situation where you want to vary the
    implementation of an abstraction at run time
  • e.g. given a fixed GraphBase you may want to vary
    the GraphImp at run-time (to suit particular
    algorithms)
  • Consider a situation where you want to allow a
    number of related abstractions each with a number
    of different implementations
  • it is then desirable for the abstractions and
    implementations to vary independently

70
Example variety of windows and systems
71
Bridge object structural
  • Synopsis Decouple an abstraction from its
    implementation so that they can vary
    independently
  • Context You can have hierarchies of windowing
    abstractions and hierarchies of windowing
    systems. If you combine the two, you will end up
    with too many classes.
  • Forces
  • you want to avoid a permanent binding between an
    abstraction and its implementation
  • both the abstractions and the implementations
    should be extensible by subclassing
  • changes in the implementation of an abstraction
    should have no impact on clients
  • you have a proliferation of classes (as in the
    example)
  • you want to share an implementation among
    multiple objects

72
Bridge object structural
  • Solution Abstractions have reference to the
    implementation and forward client requests as
    required
  • Abstraction (e.g. Window) defines the
    abstractions interface maintains a reference to
    an object of type Implementor
  • RefinedAbstraction (e.g. IconWindow) extends
    the interface defined by Abstraction
  • Implementor (e.g. WindowImp) defines the
    interface for the implementation classes. This
    interface doesnt need to correspond exactly to
    the Abstractions interface (but it may)
  • ConcreteImplementor (e.g. XWindowImp)
    implements the Implementors interface

73
Bridge object structural
74
Example variety of windows and systems
75
Bridge object structural
  • Consequences
  • Decoupling abstraction and implementation
  • an implementation is not bound permanently to a
    abstraction
  • eliminates compile-time dependencies on the
    implementation, i.e. can change implementation
    class without necessarily recompiling
  • Improved extensibility
  • the Abstraction and Implementation hierarchies
    can be extended independently
  • Hiding implementation details from clients
  • e.g. clients dont need to know if
    implementations are shared
  • Related patterns Adapter, Factory method

76
Where next?
  • Structural patterns for more flexible object
    relationships
  • Decorator
  • Behavioral patterns for more flexible object
    interaction
  • Strategy
  • Iterator
  • Reference, Gamma et.al. chapter 5
  • http//hillside.net/patterns
  • http//www.cs.wustl.edu/schmidt/patterns-info.htm
    l

77
Structural patterns
  • Sometimes you want to add capabilities/responsibil
    ities to an individual object and not to a whole
    class
  • e.g. you may want to display some objects in a
    GUI with embellishments like a border or drop
    shadow
  • e.g. you may want to add scroll bars to a
    component only when it cannot be fully displayed
    in the window
  • Using inheritance to add the capability means
    that all objects will have the additional
    properties (e.g. border)
  • Another approach is to define a class to act as a
    filter
  • it encloses the object to be embellished
  • it adds the capability required
  • such a filter can be added as required

78
Decorator object structural
  • Synopsis Add functionality (dynamically) to an
    object in a way which is transparent to its
    clients
  • Context In a GUI, you may want to add and
    retract embellishments of displayed objects, such
    as a border or shading or some highlight. It is
    not appropriate to add this to every displayed
    object, and further, you may wish to retract the
    embellishment without discarding the original
    object.
  • Forces
  • You want to extend the functionality of a number
    of objects of a given class, but you do not want
    to add this to every instance
  • There is a need to dynamically extend or withdraw
    the capabilities of objects

79
Decorator object structural
  • Solution Define a class to act as a
    wrapper/filter for the original object and which
    adds the necessary functionality. Such a wrapper
    instance can be added or removed at runtime.
  • Component defines the interface for objects
    which can have capabilities added dynamically
  • ConcreteComponent defines the objects to which
    additional capabilities can be attached
  • Decorator includes the Component interface,
    holds a reference to a component
  • ConcreteDecorator adds the required
    capabilities to a Decorator

80
Decorator object structural
81
Decorator object structural
  • Consequences
  • Decorator allows for dynamic change in the
    capabilities of components, by adding and
    removing wrappers
  • You can mix and match with a number of wrappers
    achieving a large number of possible combinations
  • Flexibility of wrappers makes them more error
    prone, e.g. using incompatible wrappers or
    getting circular references
  • Use of decorators reduces the number of classes,
    but increases the number of objects (which can
    hinder debugging)
  • The use of decorators makes it difficult to
    distinguish objects by their object identities
  • Related patterns Delegation, Filter, Strategy

82
Behavioral patterns
  • 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

83
Strategy object behavoral
  • 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
  • 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

84
Strategy object behavoral
  • 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.

85
Structural of strategy pattern
86
Example breaking test into lines
  • Composition maintains line breaks in displayed
    text it uses a Compositor to determine those
    line breaks
  • Compositor determines line breaks
    SimpleCompositor for plain text, TexCompositor
    for Tex algorithm, etc.

87
Strategy object behavoral
  • 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
  • Strategies provide a choice of implementations,
    depending for example, on different time and
    space tradeoffs

88
Strategy object behavoral
  • 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
  • Strategies provide a choice of implementations,
    depending for example, on different time and
    space tradeoffs

89
Behavioral patterns
  • Suppose we have an aggregate data structure and
    we wish to access the components without
    revealing the structure of the aggregate
  • e.g. it would be nice to be able to write
    something like
  • for (Iterator i s.iterator() i.hasNext())
  • xi.next()
  • ...
  • e.g. we may have a Set data structure and wish to
    examine the elements of the set without revealing
    whether they are stored as an array, linked list,
    etc.
  • Solution is to define an Iterator

90
Iterator object behavoral
  • Synopsis Provide a way to access the elements of
    an aggregate object sequentially without exposing
    its underlying representation
  • Context useful for accessing the components of
    any data structure, e.g. set, list, tree
  • Forces Use the Iterator pattern
  • to access an aggregate objects contents without
    exposing its internal representation
  • to support multiple traversals of aggregate
    objects
  • to provide a uniform interface for traversing
    different aggregate structures (i.e. to support
    polymorphic iteration)

91
Iterator object behavoral
  • Solution
  • Iterator defines an interface for accessing and
    traversing elements
  • ConcreteIterator (e.g. PTListIterator)
    implements the Iterator interface keeps track of
    the current position in the traversal of the
    aggregate
  • Aggregate defines an interface for creating an
    Iterator object
  • ConcreteAggregate (e.g. PTList) implements the
    Iterator creation interface to return an instance
    of the proper ConcreteIterator

92
Example a list iterator
  • PTListIterator will need to have a reference to
    the list (as indicated by the arrow in the
    diagram)
  • For scoping reasons (in Java), the PTListIterator
    will be declared as a public inner class of
    PTListonly then will the hidden components of
    PTList be accessible to the iterator, cf. friend
    in C

93
Iterator object behavoral
  • Consequences There are 3 important consequences
  • It supports variations in the traversal of an
    aggregate. Complex data structures may be
    traversed in many ways. Different iterators can
    be defined for different kinds of traversal
  • Iterators simplify the Aggregate interface. The
    Aggregate does not need to supply extra functions
    for iteration, since they are now available in a
    separate class.
  • More than one traversal can be pending on an
    aggregate. This is because each iterator keeps
    track of its own traversal state. The same effect
    would be more difficult if the aggregate stored
    the traversal state.
  • You should query the robustness of the iterator
    what happens if the aggregate is changed during
    traversal?

94
Java code for an iterator
  • Code added to the PTSet class
  • import java.util.Iterator
  • import java.util.Set
  • class PTSet implements Set // class definition
  • public class ElementIterator implements Iterator
  • // use the Iterator interface
  • int currelt 0
  • public boolean hasNext() // part of the
    Iterator interface
  • return currelt lt numElements()
  • public Object next() // part of the Iterator
    interface
  • Object result null // result will require
    coercion
  • if (hasNext())
  • result item(currelt)
  • currelt currelt1
  • return result

Use iterator Interface of Java
Generate iterator
95
Java code for an interator
  • Code added to the client class
  • import java.util.Iterator
  • class Client // class definition for some
    client
  • PTSet s new PTSet() // will process elements
    of set s
  • for (Iterator iter s.makeElementIterator()
    iter.hasNext() ) // generate the iterator
  • Element e(Element)iter.next()

96
Behavoral patterns
  • In a GUI, it is common to support undoable
    operations
  • you choose a graphical component and perform some
    operation on it
  • After that you wish to be able to undo/redo it
  • Alternatively, you may wish to have the facility
    for queuing operations, or scheduling them for
    later execution.
  • The common way to support this functionality is
    with the Command pattern

97
Command object behavoral
  • Synopsis Encapsulates a request as an object,
    thereby letting you parameterise clients with
    different requests, queue or log requests, and
    support undoable operations
  • Context support for undoable commands such as
    Cut, Copy and Paste in a GUI.
  • Forces Use the Command pattern when you want to
  • parameterise objects by an action to perform.
    (Commands are an object-oriented replacement for
    callbacks in procedural languages.)
  • specify, queue, and execute requests at different
    times. The Command object can have a lifetime
    independent of the original request
  • support undo, since a Command can store relevant
    state for reversing the effects of the command

98
Command object behavoral
  • Forces (ctd) Use the Command pattern when you
    want to
  • support logging changes so that they can be
    reapplied in case of a system crash
  • structure a system around high-level operations
    built on primitive operations. Such a structures
    is common in information systems that support
    transactions. A transaction encapsulates a set of
    changes to data. The Command pattern offers a way
    to model transactions.

99
Command object behavoral
  • Solution The requested operation is encapsulated
    in an object with sufficient data to be able to
    perform and undo it
  • Command declares an interface for executing an
    operation
  • ConcreteCommand (e.g. PasteCommand) defines a
    binding between a Receiver object and an action
    implements commit() by invoking the corresponding
    operation(s) on Receiver
  • Client (e.g. Application) creates a
    ConcreteCommand object and sets its Receiver
  • Invoker (e.g. MenuItem) asks the command to
    carry out the request
  • Receiver (e.g. Document) knows how to perform
    the operations associated with carrying out a
    request

100
Structure of command pattern
101
Example GUI commands
102
Command object behavoral
  • Consequences
  • Command decouples the object that invokes the
    operation from the one that knows how to perform
    it
  • Commands are first-class objects they can be
    manipulated and extended like any other object
  • You can assemble commands into a composite
    command
  • You can add new commands without changing
    existing classes
  • Related patterns Strategy

103
Motivating example for design patterns
  • Graphical user interfaces (GUIs) are quite
    pervasive
  • they are complex pieces of software
  • their development relies heavily on
    object-orientation
  • Much of the initial motivation for design
    patterns arose in the context of GUI development
  • no coincidence that Gamma developed key GUI
    frameworks
  • there are common problems in the GUI context
  • there are standard solutions design patterns
  • A GUI case study provides the context for
    demonstrating a number of design patterns

104
Essential features of a GUI
  • Graphical display
  • windows
  • icons
  • menus
  • User interaction via pointing device (mouse)
    keyboard
  • select window, navigate within a window
  • select object as target for operation
  • select operation via menus (or keyboard)
  • Event-driven paradigm
  • activity is determined by user interaction, not
    predetermined by program

105
Event-driven paradigm
  • Typically GUI style program
  • read a graph if the user selects appropriate menu
    item
  • modify display of graph in response to mouse
    activity
  • perform analysis in response to menu item
  • produce results if requested
  • Structure of program is based around a central
    event loop
  • repeatedly wait for an event and then process it

106
Requirements for a document editor
  • A significant design problem
  • What are the issues to be addressed?
  • Can we formulate the big picture?
  • How effective are patterns for capturing the
    design choices?
  • Document editor (called Lexi) in the style of
    Word, etc.
  • Documents consist of text graphics
  • Manipulate individual or groups of components
  • See fig 2.1 (Gamma et al) for sample screen image
  • Want flexibility in many areas
  • structure, algorithms, interface

107
Design issues
  • Document structure
  • lexible composition of document components
  • Formatting
  • flexible, configurable formatting policies
  • Embellishing the user interface
  • scroll bars, borders, drop shadows, etc.
  • Multiple look-and-feel standards
  • cant be hard-wired into the application
  • Multiple windowing systems for portability
  • User operations which are undoable
  • Spell checking and hyphenation
  • wont be considered

108
Document structure
  • A document consists of graphical components such
    as characters, lines, polygons, other shapes
  • The author will view the document as groups of
    components rows, columns, figures, tables, etc.
  • Lexi should allow the author to manipulate these
    groups directly
  • The internal document structure should support
  • maintaining the documents physical structure
  • generating and presenting the document visually
  • mapping positions on the display to document
    components (in response to mouse activity)

109
Document structure
  • Proposal is to have a recursive structure for
    graphical components

110
Document structure
  • Internal structure corresponding to previous
    slide will be tree-structured

111
Formatting strategies
  • Variety of issues could be addressed
  • e.g. how to break up the components into lines
  • what are the formatting policies?
  • can they be configured on demand?
  • Want to support a variety of strategies
    independent of the document structure

112
Embellishing the user interface
  • Want to support scroll bars, borders, etc.
  • Want to be able to do this uniformly and flexibly
  • vary these as the user interface evolves
  • even add and remove them on the fly
  • therefore cant have a fixed inheritance
    structure
  • Set up a structure for transparent enclosures
    (like a filter)
  • each enclosure has one component
  • drawing interface is the same as for the
    component
  • clients dont know if they are dealing with the
    component or the enclosure

113
Multiple look-and-feel standards
  • Look-and-feel is determined by a family of GUI
    components
  • buttons, scroll bars, pop-up menus, etc.
  • called widgets
  • Need to be able to generate consistent sets of
    widgets
  • suit a variety of styles, e.g. Motif, Windows,
    MacOS,

114
Multiple windowing systems
  • Want to support multiple window systems for
    portability
  • these vary in the level of functionality
  • should we define an abstract windowing system and
    then inherit it and override it to satisfy
    specific cases?
  • support the minimum functionality? maximum?
  • Simpler to define a windowing system that suits
    our needs
  • allow this to have a variety of implementations
  • each implementation decides how to implement the
    required operations

115
Undoable operations
  • User can request operations from different
    contexts
  • menu selection
  • mouse operation
  • palette
  • Request need to encapsulate relevant state
    information so that they can be undone

116
GUI frameworks
  • Even with object orientation, developing a GUI is
    hard work
  • learning curves of 18 months used to be quoted
  • Java APIs make it a lot easier
  • Significant breakthrough came with GUI frameworks
  • A framework is a set of cooperating classes that
    make up a reusable design for a specific class of
    software
  • It is a skeleton application which can be refined
    by inheritance
  • There are frameworks for GUIs, compiler
    construction, financial modelling

117
GUI frameworks
  • A GUI framework will include
  • generic application which will include the
    central event loop
  • central event loop will distribute events to
    relevant graphical components
  • generic documents file with contents displayed
    in a window
  • generic windows with title bar, close box, resize
    control, scroll bar
  • generic dialog windows with the ability to
    display check boxes, radio controls, buttons,
    etc.
  • configurable menu manipulation

118
Generic application
  • The Generic Application is typically encoded in a
    class called Application
  • this class is subclassed for a specific
    application
  • The Application class typically
  • includes the central event loop which is never
    modifiable
  • is instantiated once for a given run of the
    application
  • may handle multiple document types
  • has method(s) to generate documents
  • has method(s) to setup and respond to appropriate
    menus

119
Generic document
  • The Generic Document is typically encoded in a
    class called Document
  • this class is subclassed for different specific
    documents
  • The Document class typically
  • is instantiated once per document to be processed
  • has methods for fetching and storing the document
    as a file
  • has method(s) to display the document contents
  • has method(s) to setup and respond to appropriate
    menus

120
Generic view
  • The Generic View is typically encoded in a class
    called View
  • this class is subclassed for different specific
    graphical components
  • The View class typically
  • corresponds to an arbitrarily large drawing
    surface
  • contains functionality to render and print the
    component
  • contains functionality to maintain the current
    selection
  • supports various possible representations of the
    same data, e.g. spreadsheet, graph, etc.
  • has method(s) to respond to mouse events

121
Generic window
  • The Generic Window is typically encoded in a
    class called Window
  • this class is subclassed for different operating
    systems
  • The Window class typically
  • implements window-related methods like moving,
    resizing, closing
  • contains methods to optimise screen updating
  • may contain components to clip the display
  • Note that a View is a logical entity which is
    displayed in the physical entity of a Window

122
Generic classes and relationships
  • Application has multiple documents
  • Document has multiple views
  • View is displayed in a physical region
  • Window contains multiple regions

123
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com