Chapter 6Introduction to Design Patterns

(Part I)

COSC 4346: Software Engineering I

Dr. Lappoon R. Tang

Overview

Recurring Design Purposes What are Design Patterns? The abstract factory pattern

Readings

Section 6.1 Section 6.2

Review: Sample Design Goals and Ways to Accomplish Them

Reusability, Flexibility, and Maintainabilityo Reuse flexible designso Keep code at a general levelo Minimize dependency on other classes

Robustness o Reuse reliable designso Reuse robust parts

Sufficiency / Correctnesso Modularize designo Reuse trusted parts

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

Case study: KitchenViewer

Suppose we want to create an application KitchenViewer that can display a design for our kitcheno Wall cabineto Countero Floor cabinet

The application can also render a style for the kitcheno Moderno Classico Antiqueo Arts & Crafts

KitchenViewer Interface

Wallcabinet

Counter

Floorcabinet

Modern Classic Antique Arts & Crafts

menu

display area

styles

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

KitchenViewer Example

Modern Classic Antique Arts & Crafts

Wall cabinets Floor cabinetsCountertop

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

Selecting Antique Style

Modern Classic Antique Arts & CraftsAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Goals vs. Design Purposes

A design goal (such as reusability) is generally too “high level”

When confronted with an actual design problem, one needs to translate a goal into specific design purposeo Example: A goal is to reuse a part of

a calendar application, it may be translated into a specific design purpose to parameterize a set of methods so that they can be applied to any day, month, year

Design Purpose: KitchenViewer Suppose our design goal here is

flexibility To achieve the goal, what should be

our design purpose?o Example: the procedure for rendering

various styles is basically the same, there should be no need for more than one copy of this procedure renderKitchen()

More precisely, the design purpose can be stated as follows:o An application must construct a family

of objects at runtime: The design must enable choice among several styles

What are Design Patterns?

Class combinations and accompanying algorithms that fulfill common design purposes

A design pattern expresses an idea rather than a fixed class combinationo Accompanying algorithms

express the pattern’s basic operation

What are Design Patterns?

Design patterns express an idea instead of specific detailso Example: In house building, the

term ‘ranch style’ denotes a useful house pattern; it is an idea only, the specific details in building the house according to ‘ranch style’ has yet to be worked out

Bad example first: without design patterns

// Sample code for renderKitchen() – version ignoring design purpose

// Determine the style

... // Case statement

// Assume that the antique style was selected.

// Create the antique wall cabinets

AntiqueWallCabinet antiqueWallCabinet1 = new AntiqueWallCabinet();

AntiqueWallCabinet antiqueWallCabinet2 = new AntiqueWallCabinet();

...

// Create the antique floor cabinets

AntiqueFloorCabinet ...

// Create the kitchen object, assuming the existence of add() method

Kitchen antiqueKitchen = new Kitchen();

antiqueKitchen.add(antiqueWallCabinet1, ...); // rest of parameters specify location

antiqueKitchen.add(antiqueWallCabinet2, ...);

// Add antique floor cabinets to the kitchen

...

// Render antiqueKitchen

...

Bad example first: without design patterns

renderKitchen() uses the classes Kitchen, WallCabinet, FloorCabineto This method is placed in a class

called Client (conceptually the application class or a class to be used by the application class)

As you can see, the code is going to be repetitive, inflexible, and hardly reusableo One copy of such code is needed for

every type of style (e.g. modern)

KitchenViewer Without Design Patterns

Kitchen

ClientrenderKitchen()

FloorCabinet

ModernWallCabinet

ModernFloorCabinet AntiqueFloorCabinet

AntiqueWallCabinet

WallCabinet

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

Design Goal At Work: Flexibility

Our design should be flexible enough to produce any of the several kitchen styles.

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

How do we deal with the problem?

Problem: … new AntiqueWallCabinet(); Applies only to antique style because

objects of the class AntiqueWallCabinet can only access methods related to rendering antique wall cabinets

Solution: … myStyle.getWallCabinet(); The class of the object myStyle will

check at runtime which style (e.g. antique or modern?) is being rendered and then the corresponding method for rendering is used.

AntiqueKStylegetWallCabinet()getFloorCabinet()

The Abstract Factory Idea

KitchenStylegetWallCabinet()getFloorCabinet()

ModernKStylegetWallCabinet()getFloorCabinet()

WallCabinet FloorCabinet

AntiqueWallCabinet AntiqueFloorCabinet

FloorCabinet getFloorCabinet() { return new AntiqueFloorCabinet(); }

……

FloorCabinet getFloorCabinet() { return new ModernFloorCabinet(); }

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

Abstract Factory Design Pattern Applied to KitchenViewer

KitchenStylegetWallCabinet()getFloorCabinet()

KitchengetWallCabinet()getFloorcabinet()

ClientrenderKitchen( KitchenStyle )

ModernKStylegetWallCabinet()getFloorCabinet()

AntiqueKStylegetWallCabinet()getFloorCabinet()

WallCabinet FloorCabinet

ModernWallCabinet

ModernFloorCabinet

AntiqueWallCabinet

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

Abstract Factory Design Pattern Applied to KitchenViewer

// renderKitchen(KitchenStyle* myStyle) – using design pattern

// Note: Code is adapted for C++.

// Create wall cabinets, type decided by the class of myStyle

WallCabinet* wallCabinet1 = myStyle -> getWallCabinet();

WallCabinet* wallCabinet2 = myStyle -> getWallCabinet();

...

// Create floor cabinets

FloorCabinet* floorCabinet1 = myStyle -> getFloorCabinet();

FloorCabinet* floorCabinet2 = myStyle -> getFloorCabinet();

...

Kitchen kitchen = new Kitchen();

kitchen.add(wallCabinet1, ...);

kitchen.add(wallCabinet2, ...);

... // Add floor cabinet to kitchen

Abstract Factory Design Pattern

StylegetComponentA()getComponentB()

ClientdoOperation( Style myStyle )

Style1getComponentA()getComponentB()

Style2getComponentA()getComponentB()

ComponentA ComponentB

Style1ComponentA

Style1ComponentB

Style2ComponentA

Style2ComponentB

Collection

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

Abstract Factory Design PatternAlternative

StylegetComponentA()getComponentB()

ClientdoOperation()

Style1getComponentA()getComponentB()

Style2getComponentA()getComponentB()

ComponentA ComponentB

Style1ComponentA

Style1ComponentB

Style2ComponentA

Style2ComponentB

Collection getComponentA()getComponentB()

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

Key Concept: Design Pattern

-- Definition: class combination and algorithms that fulfill a common design purpose.

The abstract factory pattern:* Achieves design purposes derived from the design quality flexibility* Key ideas:

o Parameterize the methods that are supposed to be

flexible and easily extendableo Make the class containing the flexible

methods depend on or aggregate an abstract class to which

new sub-classes (thus new functionalities) can be

added.o Make the sub-classes of the abstract class

in turn depend on sub-classes of other abstract

classes needed by the design

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