UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 1 CSE 503 – Software Engineering Lecture 15: Design pattern languages Rob DeLine 17 May 2004

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 1

CSE 503 – Software Engineering

Lecture 15: Design pattern languages

Rob DeLine

17 May 2004


[Slide from Mary Shaw]






Routine design vs innovation

Engineering separates routine design from innovative design Routine: solve familiar problems using prior solutions Innovative: finding new solutions to new problems Most design is routine

Engineering disciplines record design knowledge Supports routine design Is the basis of professional education Comes in the form of handbooks and manuals


Example handbook

Contents Chemical and physical property data Fundamentals (e.g. thermodynamics) Processes (the bulk of the book)

heat transfer operationsdistillationkineticsliquid-liquidliquid-solidetc.

Materials of construction Waste management Process safety


Other precedents

Polya’s How to Solve It Catalogs techniques for solving mathematical (geometry) problems Two categories: problems to prove, problems to find/construct

Christopher Alexander’s books, e.g. A Pattern Language Saw building architecture/urban design as recurring patterns Gives 253 patterns as: name; example; context; problem; solution

Pattern languages as engineering handbooks Hype aside, it’s about recording known solutions to problems Pattern languages exist for many problems, but we’ll look at design Best known: Gamma, Helm, Johnson, Vlissides (“Gang of four”)

Design Patterns: Elements of reusable object-oriented software Notice the subtitle: here, design is about objects and their interactions


Gang of four patterns

purpose

creational structural behavioral

scope class factory method adapter (class) interpreter

template method

object abstract factory adapter (object) chain of responsibility

builder bridge command

prototype composite iterator

singleton decorator mediator

facade memento

flyweight observer

proxy state

strategy

visitor


Problem: delay choice of type

Typical OOP program hard-codes type choicesvoid AppInit () {#if MAC

Window w = new MacWindow(...);Button b = new MacButton(...);

#elseWindow w = new XpWindow(...);Button b = new XpButton(...);

#endifw.Add(b);

}

We want to easily change the app’s “look and feel”, which means calling different constructors.


Solution: factory class

Wrap the constructors in “factory methods”class LookAndFeelFactory {

LookAndFeelFactor ();Window CreateWindow (...);Button CreateButton (...);

}

void AppInit (LookAndFeelFactory factory) {Window w = factory.CreateWindow(...);Button b = factory.CreateButton(...);w.Add(b);

}


Aside: is this problem OOP-specific?

Problem arises because modules and types are coupled in OOP languages

signaure LookAndFeel =sig

type windowtype button

val makeWindow: windowParms -> windowval makeButton: buttonParms -> button

val add: window x button -> unit...

end


Problem: uniformly access sequential data

We don’t want to make data access specific to the interface

class List {List ();void Add (object element);void Remove (object element);object Head ();List Rest ();

}...for (List scan = myList; scan != null; scan =

scan.Rest()) ...

We also want multiple simultaneous traversals, different traversal orders


Solution: iterator

Put the traversal data in its own classclass List { ...

ListIterator GetIterator();}

class ListIterator {object GetCurrent ();bool Done ();void MoveToNext ();

}

for (ListIterator scan = myList.GetIterator(); ! scan.Done();scan.MoveToNext() ) ...


Problem: We need many instances

For page layout, we need many instances of lettersclass Glyph {

Page myPage;Row myRow;Column myColumn;void PrintMe ();

}

For a 10-page doc, with 1000 glyphs per page, representation needs 3*32*10*1000 = 1 MB !


Solution: Flyweight

Use a single object per unique glyph move all state outside the object itself treat the “object” as a mathematical value (functional

programming)

class Glyph {void PrintMe (Page page, Row row, Column col);

}


Problem: Too many object interconnections

In asynchronous programs, events have many reactions

void FontSelectCallback (FontDisplay fontList) {Font font = fontList.GetSelectedItem();if ( ! font.SupportsBold())

boldSelector.Deactivate();if ( ! font.SupportsItalic())

italicSelector.Deactivate();...

}

If this dialog box gets a new element, we must update many classes


Solution: mediator

Centralize the interconnection codevoid FontSelectCallback (FontDisplay fontList) {

fontList.mediator.FontChanged(fontList.GetSelectedItem());

}

class FontMediator {void FontChanged (Font newFont) {

if ( ! font.SupportsBold())boldSelector.Deactivate();if ( ! font.SupportsItalic())italicSelector.Deactivate();

}}


Problem: Adding new operation to classes

For heterogeneous data structures, traversal code gets cloned many times

class Assignment {Variable lhs;Expression rhs;void Resolve (NameEnv env) { lhs.Resolve(); rhs.Resolve(); }Type Typecheck (TypeEnv env) {

Type lhsType = lhs.Typecheck(); Type rhsType = rhs.Typecheck();if ( ! rhsType.AssignableTo(lhsType))

{ throw new TypeError(); }}Code CodeGen (TypeEnv env) {

Code lhsCode = lhs.CodeGen();Code rhsCode = rhs.CodeGen();return new

RegisterCopy(lhsCode.ResultRegister(),

rhsCode.ResultRegister()); }

}


Solution: visitor

Encapsulate traversal algorithmclass Visitor<ARGS,RESULT> {

RESULT VisitIdentifier (Ident ident, ARGS args);RESULT VisitAssignment (Assignment asst,

RESULT lhs, RESULT rhs, ARGS args);...RESULT Visit (ARGS args); // does the case split

}

class TypeCheckVisitor : Visitor<TypeEnv,Type> {TypeEnv VisitAssignment (Assignment asst, Type lhs, Type rhs, TypeEnv env) { if ( ! rhs].AssignableTo(lhs)) { throw new TypeError(); }}

}


Patterns as a design method

Pattern language contains an implicit methodology Understand your problem Look for your problem in the handbook Apply the handbook’s solution to your system

For you to discuss: What are the difficulties in applying this methodology? Is a developer better off with a pattern book than without? If so, as a researcher, how would you demonstrate this?

Documents

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 1 CSE 503 – Software Engineering Lecture 15: Design pattern languages Rob DeLine 17 May 2004