lecture 9 design patterns

Lecture 9Design Patterns

CSCI – 3350 Software Engineering II

Fall 2014

Bill Pine

CSCI 3350 Lecture 9 - 2

Lecture Overview

• Background from architecture• Basic design patterns• Standard format• Example patterns


Background

• Recall the Chess Master Analogy• The Software Design Master

– Must know, understand, and apply the deisgn patterns

• There are hundreds of these patterns• The more frequently occurring patterns

have been cataloged• We will examine a subset of these


Introduction

• Motivation: Promote reuse at design level• An o-o system is an assembly of classes• Want to leverage previous efforts• New systems contain functionality not

present in old– Else why build a new one?

• Existing classes will likely be used in different ways than originally designed


Introduction (continued)

• At least some of needed functionality will have been previously developed– Why re-invent the wheel?– Developing new implementations to familiar problems

• Is a waste of time and money while under development• Serves as an injector of faults

– And therefore a further waste of time and money

• Design patterns are an attempt to provide a body of knowledge to commonly recurring problems– In a standard format


Introduction (continued)

• The standard reference for object-oriented design patterns is the book– Title: Design Patterns: Elements of Reusable

Object-Oriented Software– Authors: Erich Gamma, Richard Helm, Ralph

Johnson, and John Vlissides– The authors are referred to as the “Gang of

Four” in object-oriented design literature


Definition

• Quote from Christopher Alexander

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”


Definition (continued)

• What is the origin of design patterns?– Conventional architecture– Proposed by Christopher Alexander– The architectural patterns described towns and

buildings

• A pattern is a bit of insight that conveys the essence of a proven solution to a commonly recurring problem


Definition (continued)

• An analogy from Jim Coplien“I could tell you how to make a dress by

specifying the route of a pair of scissors through a piece of cloth, in terms of angles and length of cut. Or, I could give you a pattern. By reading the specification, you would have no idea of what was being built. The pattern foreshadows the product; it is the rule for making the thing, but it is also, in many respects, the thing itself.”


Basic Design Patterns

• GoF describes 23 of the more commonly recurring patterns

• The patterns are classified into three categories– Creational

• Concerned with creating object• Object instantiation is deferred to a subclass

– Structural• Concerned with the composition of classes or objects

– Behavioral• How classes or object interact or distribute responsibility


Design Pattern Classification

Purpose

Creational Structural Behavioral

Class Scope Factory Method Adapter(class) InterpreterTemplate Method

Object Scope

Abstract FactoryBuilderPrototypeSingleton*

Adapter*Bridge*Composite*DecoratorFaçade*FlyweightProxy*

Chain of ResponsibilityCommandIterator*MediatorMementoObserver*StateStrategyVisitor


Standard Format

• 13 section standard format– Pattern name and classification– Scope

• Class– Deals with relationships between classes and their subclasses– Established through inheritance and are static – Fixed at compile time

• Object – Deals with relationships between objects– Set or changed at runtime and are therefore dynamic

Standard Format (cont)

– Category• Creational• Structural• Behavioral



Standard Format (continued)

– Intent• What does the pattern do?• What problem is solved?

– Also known as (optional)• Alternative names for the pattern

– Motivation• A scenario that illustrates

– The problem– How the pattern solves the problem



– Applicability• To what situation can the pattern be applied?• A diagram of the classes involved

– Uses OMT (Object Modeling Technique) not UML

– Participants• Classes or objects involved

– Collaborations• How the participants interact to carry out their

responsibilities



– Consequences• Trade-offs and results of using the pattern

– Implementation• Pitfalls, hints, and techniques• Language-specific issues

– Sample code• Code snippets to illustrate the pattern

– Known uses• Examples of the pattern found in “real” systems



– Related Patterns• Closely related patterns and differences among

patterns

• When studying a design pattern, I find it helpful to begin with– Intent– Applicability– Known uses– Motivation


Singleton (Object – Creational)

• Intent– To ensure that a class has only 1 instance– Provide a single point of access to the instance

• Applicability– Use the Singleton pattern when:

• There must be exactly 1 instance of a class• That instance must be accessible to all from 1 point


Singleton (continued)

• Known uses– Smalltalk only examples supplied by Gamma

• Motivation– To avoid conflicts, it is critical that some

classes have only 1 instance• A file system that is a class within an operating

system


Class Exercise

• Produce a list of classes that might be used to create a graph of the type shown– Your design should be highly modular

• Each aspect of the graph must be modeled as a separate class

– The actual “drawing” will be achieved by calling a low level class Plot, whose specification is supplied


Façade (Object-Structural)

• Intent– Provide a unified interface to a set of interfaces – Define a higher-level interface that make the

underlying functionality easier to use• Applicability

– You need to provide a simple interface to a complex subsystem• Many users don’t need the flexibility of the subsystem• All that flexibility is difficult to manage• Provide a default view of the subsystem


Façade (continued)

• Known uses– Compilers

• Suppose you want to compile a single line • Don’t need the hassle of calling the scanner, parser,

parse tree generator, optimizer, code generator• Provide a simple interface with defaults

• Motivation– Structure a system into a subsystem to manage

complexity– Shield the client from complex interfaces


Observer (Object-Behavioral)

• Intent– Define a one-to-many dependency between

objects so all dependents of an object are notified when the primary object changes state

• Applicability– When an object’s state changes, with this

change causing changes in other objects, but the changing object doesn’t know how many dependant objects there are


Observer (continued)

• Known uses– Model / View / Controller

• Controller gets user inputs and sends message to model

• Model performs its calculations• View displays the model’s state, when notified by

subscribe/notify protocol

• Motivation– Create a loose coupling between the objects

involved


Proxy (Object-Structural)

• Intent– To provide a placeholder for another object

• Applicability– When you need a more versatile reference than a

pointer– Client sends messages to the proxy – Proxy provides additional services

• Security• Data validation

– Can be used to delay server request until really needed


Proxy (continued)

• Known uses– Instead of inserting a complex graphic into a

document, insert a proxy– The proxy will load the real graphic when

needed

• Motivation– When you need to enhance a server– Postpone an activity until it is needed


Composite (Object-Structural)

• Intent– Decompose objects into tree structures that

represent a part/whole hierarchy

• Applicability– When you need to represent whole/part

relationship– When you want to treat objects and

composition of objects equivalently


Composite (continued)

• Known uses– File systems consist of

• Directories• Files• But directories can hold files and other directories

– Composite drawings

• Motivation– Provide a uniform treatment of objects and

composites of objects


Adapter (Object-Structural)

• Intent– Convert the interface of a class into another

interface more convenient for the client

• Applicability– When you want to use an existing class, but the

interface doesn’t match the one you need– Need to use several classes, each with different

interfaces


Adapter (continued)

• Known uses– Suppose you have a Windows application that

uses the Windows file system– You need to run the application under UNIX– Write an adapter that accepts Windows file

system calls and in turn makes the appropriate UNIX file system calls

• Motivation– You have existing classes that provide the

services you need, but not the interface


Bridge (Object-Structural)

• Intent– Decouple an abstraction from its implementation to allow

the two to vary independently• Want to provide the capability to run an application on multiple

platforms

• Applicability– When you want changes in the implementation to not

affect their clients– When you want to hide the implementation from a client

• C++ (unfortunately) refers to this as a proxy class


Bridge (continued)

• Known uses– Isolate graphic clients from the hardware –UNIX– Isolate clients using windowing from platform

specifics• Motivation

– Isolate client abstractions from their implementation

– Difference between Bridge and Adapter?• The Adapter is used for existing client code• The Bridge is an integral part of the initial design


Iterator (Object-Behavioral)

• Intent– Provide a means of accessing the elements of

an aggregate structure, sequentially, without exposing the underlying structure

• Applicability– To provide access without knowledge of the

internals of the structure– To support multiple access to the object– To provide a means of traversal that is uniform

across all aggregate structures


Iterator (continued)

• Known uses– Java

• For each loop

– Standard Template Library (C++)• Iterator class

• Motivation– Isolate the structure from the means of

traversing


Summary

• This has been only a brief introduction to design patterns

• Recall directive from the opening analogy– These designs contain patterns that must be

• Understood• Memorized• Applied repeatedly

• At best you have only begun step 1

lecture 9 design patterns

Documents

lecture overviewbackground

origin of design patterns

design patternscsci

designed csci

responsibility csci

recurring problem csci

moneydesign patterns

recurring patternsthe