1 / 17

Chapter 6 Introduction to Design Patterns (Part II)

Chapter 6 Introduction to Design Patterns (Part II). COSC 4346: Software Engineering I Dr. Lappoon R. Tang. Overview. Summary of design patterns by type Creational Structural Behavioral. Readings. Section 6.3. Types of Design Patterns.

papina
Download Presentation

Chapter 6 Introduction to Design Patterns (Part II)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 6Introduction to Design Patterns(Part II) COSC 4346: Software Engineering I Dr. Lappoon R. Tang

  2. Overview • Summary of design patterns by type • Creational • Structural • Behavioral

  3. Readings • Section 6.3

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

  5. Creational Design Patterns • Major types of creational design patterns • Factory: create objects at runtime with flexibility that constructors alone cannot provide • Abstract Factory: Create coordinated families of objects at runtime, chosen from a set of styles • Prototype: Create an aggregate object in which selected parts are essentially copies Creating many versions of the collection at runtime Constraining the objects created (e.g. ensuring that there is only one instance of its class)

  6. 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.

  7. Structural Design Patterns • Help us to arrange collections of objects in form such as linked lists or trees  • Examples of design purpose satisfied: • Adaptor: allow an application to make use of external functionality • Flyweight: Obtain the benefits of having a large number of individual objects without excessive runtime space requirements

  8. 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.

  9. Behavioral Design Patterns • Purpose: capture a kind of behavior among a collection of objects • Example application: Suppose we want to build an application such that • 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 • Based on parameters such as their size • More specifically, we need to consider mutual behavior among Ship and Tugboat

  10. 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.

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

  12. 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 

  13. Avoiding Dependencies  Harbor application 1 1..n Ship Tugboat 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.

  14. 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.

  15. Applying the Mediator Design Pattern to The Harbor Problem PortMission estimateTime() Vessel Mediator base class Ship Tugboat Note: It’s an abstract class. estimateTime is polymorphic EnteringPort estimateTime() LeavingPort estimateTime() BeingMaintained estimateTime() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  16. Behavioral Design Patterns • Example of design purposes satisfied: • 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 • Mediator: captures the interaction between objects without having them reference each other (thus permitting their reuse)

  17. 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.

More Related