Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Chapter 6 Introduction to Design Patterns _Part II_.ppt

VIEWS: 4 PAGES: 17

									              Chapter 6
   Introduction to Design Patterns
               (Part II)

COSC 4346: Software Engineering I
      Dr. Lappoon R. Tang
                   Overview

o   Summary of design patterns by type
    o Creational
    o Structural
    o Behavioral
                  Readings

o   Section 6.3
              Types of Design Patterns

o   Design patterns can generally be classified
    into one of three types based on the purpose
    of the design pattern
    o Creational
       o Purpose: creating a collection of objects in flexible
         ways
    o Structural
       o Purpose: representing a collection of related objects
    o Behavioral:
       o Purpose: capturing behavior among a collection of
         objects
                  Creational Design Patterns

    o   Major types of creational design patterns
        o Factory: create objects at runtime with flexibility
          that constructors alone cannot provide
        o Abstract Factory: Create coordinated families of
          objects at runtime, chosen from a set of styles
        o Prototype: Create an aggregate object in which
          selected parts are essentially copies


Creating many
                            Constraining the objects created
versions of the
                            (e.g. ensuring that there is
collection at
                            only one instance of its class)
runtime
Key Concept: à Creational Design Patterns ß
        -- used to create objects in
        flexible or constrained ways.




           Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
            Structural Design Patterns

o   Help us to arrange collections of objects in
    form such as linked lists or trees J
o   Examples of design purpose satisfied:
    o Adaptor: allow an application to make use of
      external functionality
    o Flyweight: Obtain the benefits of having a large
      number of individual objects without excessive
      runtime space requirements
Key Concept: à Structural Design Patterns ß
 -- used to represent data structures such as
 trees, with uniform processing interfaces.




            Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
            Behavioral Design Patterns

o   Purpose: capture a kind of behavior among
    a collection of objects
o   Example application: Suppose we want to
    build an application such that
    o It can estimate the amount of time required to
      bring ships into and out of a harbor and
      transport them to dry dock for maintenance
       o Based on parameters such as their size
       o More specifically, we need to consider mutual
         behavior among Ship and Tugboat
Example of Behavioral
Design: Port Traffic




          obstacles




                                                                                             to drydock à



            berth                                                           berth
                      Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
             Behavior Design Patterns

o   Ship and Tugboat are natural choices for
    classes
    o But objects of these classes can play different
      roles depending on whether the ship is arriving,
      leaving or heading for the dry dock
o   We have a situation here because:
    o We want to be able to model correlation among
      objects of Ship and Tugboat
    o We do not want Ship and Tugboat to depend on
      each other as we can use them in other
      applications
       Behavior Design Patterns



Core idea: We can use a behavior
design pattern here because we want to
separate the inter-dependent behavior
of these objects from the objects
themselves J
                                                         ´
                                             Harbor application
                                    1                                              1..n
                     Ship                                                                            Tugboat
Avoiding
Dependencies            Customs application: reuse Ship alone

                                        Ship                                 Workman


• Estimating the time needed for a particular event (e.g. leaving port)
involving an object of Ship and an object of Tugboat by having an
association relation between the two classes is a bad idea – none
of the two classes can be reused in a different application



                     Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
  Core Mediator Concept Applied to The Harbor Problem

                                                                                            Ship
        LeavingPort
       estimateTime()
                                                                                            Tugboat



• We need a class that plays the role of a “mediator” that has direct
control over objects from Ship and Tugboat so that the time for
leaving port can be estimated in this class




                     Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
   Applying the Mediator Design Pattern to The Harbor Problem

        PortMission                                                                            Vessel
       estimateTime()

                              Mediator base class
                                                                                 Ship                         Tugboat
Note: It’s an
abstract
class.
estimateTimeis
                                       EnteringPort
polymorphic J                         estimateTime()


                   LeavingPort
                  estimateTime()

      BeingMaintained
       estimateTime()    Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
            Behavioral Design Patterns

o   Example of design purposes satisfied:
    o Chain of responsibility: we want a collection of
      objects to exhibit functionality. At design time
      we want to be able to easily add or delete objects
      that handle all or part of the responsibility
    o Mediator: captures the interaction between
      objects without having them reference each
      other (thus permitting their reuse)
Key Concept: à Behavioral Design Patterns ß
-- Purpose: the design captures behaviors and/or
          interactions among objects.




            Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

								
To top