CISC 323 Intro to Software Engineering Week 6: Design Patterns CISC - - PowerPoint PPT Presentation

CISC 323 Intro to Software Engineering

Week 6: Design Patterns

CISC 323 Intro to Software Engineering

Lecture 6-1 Introduction to Design Patterns

• ✁

• ✒

• Review of Quality Attributes
• Recall

– Requirements analysis determines desired quality attributes of system – When designing system, attempt to

– Some attributes amenable to mathematical expression (performance, availability), others less so (modifiability)

• ✁

Example Quality Attributes

• Performance
• Availability
• Security
• Modifiability
• Usability
• Testability

• ✁

Design Choices Trade Off Quality Attributes

• E.g., to obtain performance, may need to use

a very complex algorithm, reducing modifiability

• E.g., to obtain availability, may need to

replicate data sources, reducing security

• Therefore, design choices rely on knowing

required targets for quality attributes

– At what point is security sufficient? – At what point is system sufficiently fast? – … Etc.

• ✁

Design Patterns

• Software architecture normally covers the

large-scale design of software systems

• Within architectural components, it can be

useful to apply micro-architectures to help design these components

– Sometimes called design patterns

• ✁

Design Patterns

• A design pattern is a set of rules of how to

structure code in order to solve a particular class of problem

• Provides vocabulary to discuss design
• Particularly suited to OO design as patterns

can be expressed in terms of classes, associations

• Design patterns normally help in improving at

least one quality attribute, perhaps at the expense of others

• ✁

Example: the Publish and Subscribe Design Pattern

• Problem

– A data source is shared by a number of clients – Multiple clients depend on the value of the data source – Modifiability attribute important

• ✁

Concrete Example: Expense Report

Item $US Cost $Cdn Cost Total cost ($Cdn) Air $670 $670 Hotel $980 $1470 Meals $70 $105 TOTAL $1050 $670 $1245

Forms-based interface for calculating expense reports.

• ✁

Concrete Example: Expense Report

Item $US Cost $Cdn Cost Total cost ($Cdn) Air $670 $670 Hotel $980 $1470 Meals $70 $105 TOTAL $1050 $670 $1245

Items depend on value of exchange rate. If exchange rate changes, these values should change too.

• ✁

Dependencies

Exchange Rate $Cdn cost of hotel $US cost of hotel $Cdn cost of meals $US cost of meals depends depends depends depends

• ✒

Problem

• When exchange rate modified, must update values of

all components that depend on it

• ✁

• ✁

Exchange Rate $Cdn cost of hotel $US cost of hotel $Cdn cost of meals $US cost of meals depends depends depends depends

• ✁

Solution: Publish and Subscribe Design Pattern

• A source component

contains data on which a set of client components depend (e.g., current exchange rate)

• The client components

subscribe to changes in the data

• The source component

publishes any changes in the data

Exchange Rate $Cdn cost of hotel (1) Client component subscribes to changes in exchange rate (2) Source component publishes changes in exchange rate

• ✂

Solution: Publish and Subscribe Design Pattern

• Advantages
• ✁

• ✁

• ✂

Exchange Rate $Cdn cost of hotel (1) subscribe (2) publish

Subscriber Publisher

• ✂

Implementing Design Patterns

• Design patterns represents strategies for
• rganizing code, not explicit implementations
• Actual implementation used must be

determined on a case-by-case basis

• ✁

Event-Connector Implementation

• ❇

Exchange Rate $Cdn cost of hotel (1) subscribe = connectAsTarget (2) publish = raiseEvent

Subscriber Publisher

• ✁

Code for Target (Subscriber) Interface

// Target implements this method. It is called by the // event connector whenever a new event is fired. public interface EventTarget { public void performEvent (EventObject e); }

• ✂

Code for New Event Type

import java.util.EventObject; public class ExchangeRateChangedEvent extends EventObject { private float newExchangeRate; public int getNewExchangeRate () { return newExchangeRate; } public ExchangeRateChangedEvent ( Object source, float newRate) { super (source); newExchangeRate = newRate; } }

• ✂

EventConnector (Publisher) Code

public class EventConnector { //There are zero or more targets represented as a vector private Vector targets = new Vector(); // When a new event is raised, the "performEvent" method of // each target is invoked public void raiseEvent (EventObject e) { for (int i=0; i<targets.size(); i++) { EventTarget t = (EventTarget) targets.elementAt (i); t.performEvent (e); } } //Each target must register itself as a target of this //connector. public void connectAsTarget (EventTarget targetComponent) { targets.add(targetComponent); } }

More on Publish/Subscribe

• Basis of the Event-based Architectural Style
• Greatly improves modifiability and

extendibility of systems

– At the expense of interaction complexity – which may make analysis more difficult

• Used in most (all) graphical user interface

frameworks

• Also very popular in development

environments (e.g. IBM Eclipse) where a variety of tools can be easily integrated

• ✁

• ✒

• ✒

Sequence Diagram

Publisher Subscriber1 Subscriber2

connectAsTarget connectAsTarget raiseEvent (change in state initiated by outside source or Publisher) performEvent performEvent

• ✂

• ✒

• ✒

Where do Design Patterns Come From?

• Actually mined from code

– General rule -- design pattern must be seen in at least three real systems before it is considered to be a design pattern

• ✒

• ✒

• ✒

Reading

• Bahrami mentions design patterns, no details
• Supplementary text for this topic:
• ✁✄✂

• ✕

• pages for each design pattern listed on web & slides
• pages for publish/subscribe pattern: 293-303
• ✾✓✆

• note: this text uses C++/Smalltalk, UML-like notation
• ✖

CISC 323 Intro to Software Engineering

Lecture 6-2 Adapter, Façade, Abstract Factory, and Flyweight Design Patterns

• ✁

• ✒

• ✒

Adapter Design Pattern [Gamma et al., pp 139-150]

• Motivation

– Sometimes a class implements functionality similar to what an application requires, but not the correct interface for that application – E.g. We wish to implement a BookList class implementing a list of text book used in a course

int getNumBooks() Book getBook (int n) void addBook (Book newBook)

– These operations are very similar to the

• perations in the predefined Vector class

• ✂

• ✒

• ✒

Adapter Design Pattern

• Options:

– Implement BookList from scratch

– Use Vector

– Adapt Vector to BookList interface

• ✁

• ✒

• ✒

Adapter

• Two ways of adapting the Vector

– Class adapter

– Object adapter

• ✂

• ✒

• ✒

Class Adapter

• ✂

• ✒

• ✒

Class Adapter

public interface BookList { public int getNumBooks(); public Book getBook(int n); public void addBook(Book newBook); }

BookList.java

import java.util.Vector; public class BookListClassAdapter extends Vector implements BookList { public int getNumBooks() { return size(); } public Book getBook(int n) { return (Book) elementAt(n); } public void addBook(Book newBook) { for (int i=0; i<getNumBooks(); i++) { Book b=getBook(i); if (b.isSameBook (newBook)) { b.setQuantity (b.getQuantity() + newBook.getQuantity()); return; } } add (newBook); } }

BookListClassAdapter.java

• ✁

• ✓

• // This code simply shows how a book list is instantiated

public class SampleClient { public static void main (String [] args) { Book b = new Book (…); BookList bl = new BookListClassAdapter (); bl.addBook (b); System.out.println (“Book list has ” + bl.getNumBooks() + “ books”); } }

SampleClient.java

• ✓

• Class Adapter
• Adapter simply inherits operations of Vector
• Clients use BookList interface, not

BookListClassAdapter directly

• ✁

• ✁

• ✒

• General Form of Class Adapter

• ✁

• ✒

• Object Adapter

Object Adapter

import java.util.Vector; public class BookListObjectAdapter implements BookList { private Vector books = new Vector(); public int getNumBooks() { return books.size(); } public Book getBook(int n) { return (Book) books.elementAt(n); } public void addBook(Book newBook) { for (int i=0; i<getNumBooks(); i++) { Book b=getBook(i); if (b.isSameBook (newBook)) { b.setQuantity (b.getQuantity() + newBook.getQuantity()); return; } } books.add (newBook); } }

BookListObjectAdapter.java

• ✁

• ✒

• // This code simply shows how a book list is instantiated

public class SampleClient { public static void main (String [] args) { Book b = new Book (…); BookList bl = new BookListObjectAdapter (); bl.addBook (b); System.out.println (“Book list has ” + bl.getNumBooks() + “ books”); } }

SampleClient.java

• ✁

• ✒

• General Form of Object Adapter

• ✁

• ✒

• Relation to Quality Attributes
• Modifiability

– Adapter class provides clean interface to clients of adapted object

• Reusability

– Takes advantage of adapted class for reuse

• Correctness

– Takes advantage of tested code

• ✓

• The Façade Pattern

[Gamma et al., pp 185-193]

• Motivation

– Sometimes part of a system is itself implemented as a subsystem, consisting of a set of objects – Rather than revealing subsystem structure to rest

• f system, use façade object to provide interface

to subsystem as a whole

• ✁

• ✓

• General Idea

client classes subsystem classes Facade

• ✂

• ✓

• The Façade Pattern
• Example

– A student information system provides access to functions on

– Implemented via three classes

• ✁

Student Information System Classes

class Courses { … public StudentList getEnrollment (CourseId c) { … } … } class Students { … public CourseList getCourses (StudentId s) { … } } class Facilities { … public LectureHallId getLectureHall (CourseId c) { … } }

Courses.java Students.java Facilities.java

• ✒

Student Information System without Façade

Student Information Subsystem

• ✂

Student Information System with Façade

Student Information Subsystem

• ✂

Façade Implementation

public class StudentInformation System { Courses cs; Students ss; Facilities fs; … public StudentList getEnrollment (CourseId c) { return cs.getEnrollment (c); } public CourseList getCourses (StudentId s) { return ss.getCourses (s); } public LectureHallId getLectureHall (CourseId c) { return fs.getLectureHall (c); } }

StudentInformationSystem.java

• ✂

Relation to Quality Attributes

• Modifiability

– By removing external links to subsystem components, impact of changes to subsystem components limited to subsystem itself

• Performance

– Slight performance cost of extra call indirection through façade

Another Example: SavitchIn

• Input with Java API:

• ✾

• SavitchIn:

• ✁

Categories of Patterns

• The patterns we have seen so far address

structural problems in programs

– Adapter -- structures programs to aid reuse – Façade -- localizes references to a subsystem, aiding modifiability

• Also interesting are

– Creational patterns -- help in object creation – Behavioural patterns -- help manage runtime behaviour of program

• ✁

Abstract Factory

[Gamma et al., pp. 87-95]

• Motivation

– Imagine you have a book ordering system in which you need to maintain a list of books

– Initially, you wish to maintain a simple Vector – However, after the system has been delivered, you decide you want a data structure that also permits books to be represented in sorted order

import java.util.Vector; public class BookListClassAdapter extends Vector implements BookList { public int getNumBooks() { return size(); } public Book getBook(int n) { return (Book) elementAt(n); } public void addBook(Book newBook) { for (int i=0; i<getNumBooks(); i++) { Book b=getBook(i); if (b.isSameBook (newBook)) { b.setQuantity (b.getQuantity() + newBook.getQuantity()); return; } } add (newBook); } }

Here is an initial implementation of a BookList

Abstract Factory

• Adding sorting behavior to the BookList class

– Option 1: Modify BookList so that every time a book is entered, the Vector is sorted

• ✁

Abstract Factory

• Option 2:

– Create a BookList interface with the required functionality of maintaining a list of books – Create an abstract factory class that creates an instance of the correct kind of BookList

• ✒

BookList variants

• ✁✄✂

Problems with Changing Implementations

• Problem: If we change from the

VectorBookList to SortingVectorBookList implementation, need to ensure that wherever we create a book list, we replace “new VectorBookList()” with “new SortingVectorBookList()”

• This could be a large change

– What if source to classes creating book lists is not available?

• ✂

Abstract Factory

• ✂

Abstract Factory

BookListFactory

public interface BookListFactory { public BookList createBookList (); } class VectorBookListFactory implements BookListFactory { public BookList createBookList () { return new VectorBookList (); } } class Client { … BookListFactory blf; … BookList b = blf.createBookList(); }

BookListFactory.java VectorBookListFactory.java Client.java

• ✁

Extending to Multiple Factories

The client is provided with an object of type

• BookList. This object may be either a

VectorBookList or a SortingVectorBookList, depending on which factory was used.

BookListFactory Client uses VectorBookListFactory SortingVectorBookListFactory <<interface>> BookList uses VectorBookList SortingVectorBookList creates creates

• ✂

Extending to Multiple Factories

The client is provided with an object of type

• BookList. This object may be either a

VectorBookList or a SortingVectorBookList, depending on which factory was used.

BookListFactory Client uses VectorBookListFactory SortingVectorBookListFactory <<interface>> BookList uses VectorBookList SortingVectorBookList creates creates

Extending to Multiple Factories

The client sees an object of type BookListFactory, so does not need to know whether it is using a VectorBookListFactory

• r a SortingVectorBookListFactory

BookListFactory Client uses VectorBookListFactory SortingVectorBookListFactory <<interface>> BookList uses VectorBookList SortingVectorBookList creates creates

General Form of Abstract Factory

• ✓

Relating to Quality Attributes

• Modifiability

– Increased through use of indirection in creation process – Creator does not need to know exactly what type

• f object is being created

The Flyweight Pattern

[Gamma et al., pp 195-206]

• Sometimes objects too expensive for

applications where large numbers of objects required

• Flyweight objects provide cheaper object

mechanism

• Illustrates abstract factory pattern

• ✂

Flyweight

• In a text editor, wish to

represent a set of rows, and within each row a set of columns

• Each row in turn contains a

set of characters

• Logically, each character is

an object

• However, a document of

tens of thousands of characters would require tens of thousands of objects

a p p a r e n t

• ✂

Flyweight

a p p a r e n t a b c d e f g h i k l m n

• p

q r s t u v w x y z

• ✁

Flyweight

• Intrinsic state: data that

can be shared by many instances of object

• Extrinsic state: specific

to a particular instance

a p p a r e n t a b c d e f g h i k l m n

• p

q r s t u v w x y z

• ✁

Flyweight Implementation

create (intrinsicData)

• Client creates flyweight instances using flyweightFactory
• Factory requires intrinsic data as parameter -- e.g., parameter is

“a” to create instance of character “a”

• Factory returns flyweight object with this intrinsic data
• Client must maintain extrinsic data -- e.g., character font, position

• ✂

Relation to Quality Attributes

• Performance

– Systems with tens/hundreds of thousands or more

• f objects can be prohibitively expensive in

memory use – Flyweight objects reduce this expense

• Modifiability

– Encapsulation of system functionality no longer as clear – Separation of intrinsic/extrinsic state into different

• bjects

CISC 323 Intro to Software Engineering

Lecture 6-3 Composite, Iterator, and Builder Design Patterns

• ✁

Composite Design Pattern

[Gamma et. al. pp.163-173]

• Intent

– To compose object into tree structures that represent part-whole hierarchies – Lets clients treat individual objects and compositions of objects uniformly

• ✂

Motivation

• Problem:

• Solution: Use the composite design pattern

• ✁

Applicability

• Use the Composite pattern if…

– You want to represent part-whole hierarchies of

• bjects.

– You want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.

• ✒

Example: Swing Components

• Component

• Leaf (atomic components)

• Composite (top-level Swing

containers)

Given a frame containing multiple panes, each with multiple buttons/labels/checkboxes…

• Call paint() method on frame

causes everything to be painted.

• Changing the look and feel on the

frame is likewise propagated down.

Participants

• Component

• Leaf

• Composite

• Client

• ✂

Structure

Leaf

• peration()

Client Component

• peration()

addComponent() removeComponent() getChild() Composite

• peration()

addComponent() removeComponent() getChild() 0..* 0..* +children

• ✂

Collaborations

• Collaborations

– Client uses component class interface to interact with objects in composite structure. – If recipient is:

• ✁

Consequences

• ❅❆

• ◆
• ❍
• ❇

• ❍

• ❍

• ◆
• ❍
• ❇

• ❆

• ❊

• ❆

• ❅❆

• ❆

• ❍

• ❆

• ❆

• ■

• ◆

• ■

• ◆
• ❍
• ❇

• ❆

• ✁

Question?

• Why is Composite considered a design pattern and

not just an example of polymorphism?

• ✂

The Iterator Pattern

[Gamma et al, pp 257-271]

for (int i=0; i < v.size(); i++) { … Object o = v.elementAt(i); … }

Move to next element in list Current element First element Last element

The Iterator Pattern

• Iteration allows a program to successively

visit each element in a container class

– I.e. over any class that contains a collection of elements

• List (Vector), Tree, Hash Table, Graph, …

• ✁

Iterators in Java

public interface Enumeration { // Returns true as long as there are more // elements to visit boolean hasMoreElements(); // Returns next element to visit Object nextElement(); }

Iterators in Java

// Returns all elements in the Vector public Enumeration elements();

// Returns all elements in the Hashtable. // That is, returns all values that have been // entered into the hashtable via put public Enumeration elements();

Example: Using an Iterator with a Vector

• ✂

Using an Iterator with a Vector

• Client creates an iterator

by calling the Vector’s elements method

• Client then accesses

elements of Vector via Enumeration’s methods

for (Enumeration e = v.elements(); e.hasMoreElements();) { Object o = e.nextElement(); … }

• ✁

Implementation of Iterator for Vector

• Vector must implement method

– Enumeration elements () – Must return an implementation of the Enumeration interface – Iterator must successively return values in vector

Classes for Vector Iterator

class Vector { … public Enumeration elements () { return new VectorEnumeration (this); } … }

How we might implement an enumeration in a vector. (Not necessarily how it is really implemented.)

import java.util.Vector; class VectorEnumeration { // Represents where we are in the vector private int currentElement = 0; // The vector we are iterating through private Vector v; public boolean hasMoreElements () { return (currentElement < v.size()); } public Object nextElement () { Object returnElement = v.get (currentElement); currentElement++; return returnElement; } public VectorEnumeration (Vector v) { this.v = v; } }

• ✂

General Form of Iterator

Abstract representation

• f container

Concrete representation

• f container - e.g. Vector

Concrete iterator for specific container class - e.g. iterator for Vector is different from iterator for hashtable Enumeration interface

• ✂

Relation to Quality Attributes

• Modifiability

– Separates iteration behaviour from specifics of container class – Therefore can change container class without impacting code that iterates over it

• Performance

– May be some minor performance penalty through indirection in iterator

• ✂

Builder Design Pattern

[Gamma et. al. pp. 97-106]

• Intent

– Separate the construction of a complex object from its representation

• ✓

Applicability

• Use the Builder pattern when…

– The algorithm for creating a complex object should be independent of the parts that make up the object and how they’re assembled – The construction process must allow different representations for the object that’s constructed

• ✒

Participants

• ✁✄✂

• ✤✄✥

• ✳

• ✴✄✟

• ✁

Example: JDOM SAXBuilder

• Constructs products from an XML document.

• ★

• ✁

Structure

ConcreteBuilder buildPart() getProduct() Product Director Builder buildPart() <<creates>>

• ✂

Collaborations

• The client creates the Director object and

configures it with the desired Builder object

• Director notifies the Builder whenever a part
• f the product should be built
• Builder handles requests from the director

and adds parts to the product

• The client retrieves the product from the

builder

• ✁

Collaborations (cont’d)

aClient : Client aDirector : Director aConcreteBuilder : ConcreteBuilder new ConcreteBuilder() new Director(aConcreteBuilder) construct() buildPartA() buildPartB() buildPartC() getResult()

• ✂

Consequences

• Benefits

– It lets you vary a product’s internal representation – It isolates code for construction and representation – It gives you finer control over the construction process (object constructed step-by-step under the director’s control)

• Disadvantages

– N/A

• ✂

Relationship between Composite, Iterator, and Builder

• Builder, Composite and Iterator Design Patterns often

work together

• ✁

• ✁

Summary of Patterns Discussed…

• Creational Patterns:

• Structural Patterns:

• Behavioural Patterns:

• ✁
• ✂

Final Points

• Design Patterns encapsulate generic solutions to

commonly occurring problems in design

• ✎

• The Gang of Four text was the first widely read work
• n patterns, and remains a widely cited and used

reference

• Patterns rarely exist on their own, they often work

together to solve complex problems

• There are always costs and benefits to applying a

given pattern, which must be carefully weighed.