Design Patterns

1
Design Patterns
2
Patterns

• 1, 2, 3,
• is a sequence that exhibits the pattern
• The integers in their natural order

3
Another Sequence

• 1, 3, 5,
• The pattern
• The odd integers, in order

4
What is a Pattern?

• A template or model for imitation
• A dress pattern
• A cookie cutter
• As we shall see, an OO design diagram
• A set of rules
• For the Fibonacci sequence, the rule is
• the ith element (except for f0 and f1) is equal
  to the sum of the (i-1)st element and the (i-2)nd
  element.

5
Why are Patterns Useful?

• Patterns describing infinite sequences eliminate
  having to enumerate all values
• 0, 1, 1, 2, 3, 5, 8,
• Dont have to list all the elements

6
Why are Patterns Useful?

• A pattern can be a convenient membership test for
  a set of elements
• Regular expressions denote patterns of strings
• For example
• a-zA-Za-zA-z0-9
• is a pattern representing identifiers
• Compilers use regular expressions to test for
  identifiers

7
Why are Patterns Useful?

• Knowledge of a pattern can enable one to easily
  produce new objects

8
Why are Patterns Useful?

• In particular, patterns discerned from existing
  situations may be applied to new situations
• a, b, c,
• Monday, Tuesday, Wednesday,

9
But Sometimes the Similarities are not Obvious
Beat your plowshares into swords
10
Which Bring Us To
Patterns and Abstraction

• Do
• 1, 2, 3,
• and
• Monday, Tuesday, Wednesday,
• exhibit the same pattern?

11
Patterns and Abstraction

• 1, 2, 3,
• the integers in their natural order
• Monday, Tuesday, Wednesday,
• the days of the week in their natural order
• Are these the same pattern?

12
Patterns and Abstraction

• The pattern we really mean is
• The elements of some sequence taken in their
  natural order
• What about the fact that the integers are
  infinite and the days of the week are finite?

13
Some Patterns are Simple

• ABC
• Jackson 5
• Michael you went to school to learn,
  girlThings you never, never knew before...
• Jermaine sit yourself down, take a seatAll
  you gotta do is repeat after me.J5 a b
  cMichael easy as...J5 1 2 3Michael or
  simple as...J5 do re miMichael abc, 123,
  baby, you and me girl!

14
Others are Less Obvious

• 2, 3, 5, 7,
• primes
• March, April, June,
• Months without a Y in their names in natural
  order
• Mensa likes to use patterns like these as part of
  their qualification test

15
Some are Quite Difficult

• 6, 28, 496,
• perfect numbers
• e, t, a,
• most frequent letters in the English language in
  descending order

16
And Some are Just Downright Ornery
Especially if theyre not mathematical and you
dont know the context

• 214, 232, 234,
• Classrooms on 2nd floor of New Ingersoll from
  east to west
• 1.5, 4.1, 11,
• For cryin out loud youre CIS majors!

17
Patterns Within Patterns
A
B
C
18
and Patterns of Patterns
1, 2, 3, 1, 3, 5, 1, 4, 7, ??, ?? ??,
19
And Now For Something Completely
DifferentSumming Integers Read from a File (C)

• cin gtgt i
• while (i gt 0)
• total i
• cin gtgt i

20
Finding the Questions in a File (Java)

• line br.readLine()
• while (line ! null)
• if (line.indexOf("?") gt 0)
• questions.add(line)
• line br.readLine()

21
Building a String from a Line of Characters (C)

• i 0
• C getchar()
• while (c ! \n c ! EOF)
• si c
• C getchar()
• Si \0

22
Three Individual Pieces of Code

• Different datum types
• int, String, char
• Different end-of-input conditions
• negative datum, end-of-file, end-of-line/end-of-fi
  le
• Different tasks
• summing, maximum, string construction
• Different languages!!

23
and Yet A Pattern Emerges

• In all three cases
• Values are read from a file
• A condition is used to test for end-of-input
• The values are processed in some fashion
• A priming-the-pump technique is used
• Probably the first pattern you learn in CS 1

24
An Input Loop Pattern

• read first item
• while (not end-of-input)
• process item
• read next item

25
Why Are Such Patterns Useful?

• Avoids reinventing the wheel
• Avoids making the same mistakes over and over
  again
• Speeds up the development process
• Reusability of sorts

26
Design Patterns

• Pattern concept applied to software design
• Not a finished product
• Reuseability of design ideas
• Many patterns crop up over and over again

27
A Non-Software Example- Flywheel

• A flywheel is a massive rotating disk
• The basic idea is to accelerate the flywheel to a
  very high speed and thus maintain the energy as
  rotational energy using the disk.

28
Flywheel - Samples
29
Why a Flywheel?

• In the 70s engineers were looking for a
  low-emissions, non-internal-combustion vehicle.
• Wanted to be able to charge the vehicle and
  have it store that charge
• Charging involved bringing the flywheel up to a
  high speed
• Batteries were too bulky, heavy
• Would need tens of batteries for a small vehicle

30
Flywheel Useful For

• Storing kinetic energy often in a fairly small
  space
• Maintaining a uniform force.
• Production of high power pulses
• Can also be used to create a form of gyroscopic
  effect

31
Flywheel Advantages

• Not affected by temperature changes
• No limit to energy stored
• Simple to measure stored force (measure rotation
  speed)

32
Flywheel Disadvantages

• Danger of explosive shattering of wheel

33
Flywheel Parts

• Massive wheel
• Axle
• Bearings

34
Flywheel - Applications

• Low-cost toys (the kind you wind up by running
  the wheels along the floor)
• Energy-efficient cars (during braking, surplus
  energy is used to accelerate the flywheel which
  can subsequently power the driveshaft)
• Potters wheel
• Used on satellites to point the instruments in
  correct direction

35
Flywheel - Summary

• Note the variety of applications
• Yet all use the same basic design pattern

36
Flywheel - Summary

• Notice what we did here
• Provided a motivational situation (low-emission
  vehicle)
• Presented the purpose of the flywheel
• Described when to use one
• Presented the parts of the flywheel
• Discussed advantages and disadvantages
• Gave known applications
• Presented some samples

37
A Simple Software Example

• Youve got a program from CIS 22
• Written in C
• Uses a stack class template
• Which you wrote (whole point of assignment)

• Massive application
• Hundreds of modules
• Thousands of lines of code
• Ok, Ok, two hundred lines of code in one file
• But still, stack usage is scattered throughout
  system

38
But First-A Word From Our Sponsors

• For those of you who may not know
• a class, is essentially a structure that contain
  contain functions as well as fields.
• a template is a parameterized piece of code whose
  arguments are supplied by the application
  programmer
• Thus, a stack class template is a definition of a
  stack class in which the element type of the
  stack is supplied when a particular stack is
  declared
• stackltintgt si // stack of ints
• stackltActivationRecordgt sa // stack of
  ActivationRecords

39
Back To Our Simple Software Example

• After CIS 22, you learn about the STL (Standard
  Template Library)
• Library of useful data structures, including
  those you learned in 22
• You decide you want to play with it
• Good to know for a tech interview
• So you toss out your stack and begin using the
  one from the STL

40
The Problem

• Your stacks operations
• push places argument on top of stack
• pop pops stack returning value
• isEmpty true if empty
• STLs stacks operations
• push same
• top returns top of stack
• pop pops stack, no value returned
• empty same semantics

E pop() E elem arrtop top-- return e
void pop() top-- E top() return arrtop
41
Solution 1

• Change the application code to conform to the new
  operations
• Change all occurrences of isEmpty to empty
• Replace pop (which used to return the element)
  with a top followed by a pop

s.top() s.pop()
s.pop()
42
??? !!!
void clear() while(!s.isEmpty()) s.pop()
void clear() while(!s.empty()) s.top() s.p
op()
!!! Scratch that solution!!
43
So??

• Whats Plan B?

44
Plan B

• Add a new class, StackAdapter
• StackAdapter declares a member variable of type
  stack (from the STL).
• StackAdapter defines functions corresponding to
  the ones in your original stack class
• Some of the functions do nothing more than call
  corresponding functions of the STL stack type
• Other functions act as adapters between the old
  and new semantics
• In particular, StackAdapters pop function will
  carry out the necessary (STL) top and pop
  operations on the STL stack

45
The StackAdapter Class

• template ltclass Egt
• class StackAdapter
• public
• push(E val) s.push(val)
• E pop()
• E x s.top()
• s.pop()
• return x
• bool isEmpty() return s.empty()
• private
• stackltEgt s // STL stack

46
The Adapter Pattern

• Plan B employs a design pattern known as Adapter
• The Adapter pattern
• Converts the interface of a class into another
  interface clients expect. Adapter lets classes
  work together that otherwise couldnt because of
  incompatible interfaces

47
The Adapter Pattern Visually
StackAdapter push() pop() isEmpty()
x s. peek() s.pop() return x
s.isEmpty()
Stack push() pop() empty()
s
48
You May Have Seen Something Similar

• For example, when coding binary search
• The recursive call for binary search is
• bool binsrch(int a, int lo, int hi, int val)
• i.e, upper and lower bound parameters are
  required
• but the user of the search wants to make the
  call
• bool binsearch(int a, int n, int val)
• that is, simply the number of elements (thats
  the standard signature for an array search in
  C/C)

49
Using A Wrapper Function

• The classical resolution to this problem is to
  add an intermediary function
• bool binsearch(int a, int n)
• return binsrch(a, 0, n-1)
• This is the the procedural analogy of the
  Adapter pattern binsearch is usually called a
  wrapper function. This pattern is often taught in
  15 or 22.

50
Design Patterns

• Introduced by architect Christopher Alexander (A
  Pattern Language Towns, Buildings, Construction)
  in the context of buildings and towns
• Each pattern describes a problem which occurs
  over and over again in our environment, the
  describes the core of the solution to that
  problem, in such a way that you can use the
  solution a million times over, without ever doing
  it the same way twice.

51
Architectural Design Patterns

• A PLACE TO WAIT
• Bus stop
• Waiting room
• adresses the common aspects of their design
• ARCADES- covered walkways at edges of buildings,
  partly inside, partly outside
• http//architypes.net/patterns.php

52
The Gang of Four Book

• Introduced design patterns to software design
• Much of this talk based upon this text
• In fact, its fair to say that one purpose of
  this talk is to provide a guide to how to read
  this text
• Bulk of text is a catalog of patterns

53
Why Only Object-Oriented?

• Wouldnt this have been useful before as well?
• Designing object-oriented software is hard, and
  designing reusable objected-oriented software is
  even harder
• (Opening sentence of Design Patterns, Gamma,
  et al)
• The number and complexity of classes, objects and
  their interactions makes proper design a
  formidable task
• Also, might have been applicable before, but OOP
  (compared to say, procedural) maxes out on
  reusability
• More opportunities for reuseable design
• Everybody says that, but lets see why

54
OOP and Reusability

• So WHAT makes objected-oriented software more
  reusable than say applications designed and coded
  in a procedural style?
• Classes?
• Inheritance
• Overloaded operators?
• Access control?
• Polymorphism

55
Reusability Mechanisms Inheritance

• Allows one class to reuse another classs
  implementation (code) as its own
• All state (variables) and behavior (functions) of
  the existing (super/base/parent)class become part
  of the new (sub/child)class.
• The new subclass can then add its own
  state/behavior
• The subclass is said to be a subtype of the
  superclass type
• Not available in traditional procedural languages

56
Reusability Mechanisms - Inheritance

• class Counter
• Counter() val 0
• void up(val
• void down() val--
• int get() return val
• int val

class BoundedCounter extends Counter
BoundedCounter(int m) max m void
up() if (val lt max) val int max
57
Reusability Mechanisms - Composition

• Assembling or composing objects to get new
  functionality
• Basically one class contained as a variable of
  another
• Reusability comes from
• The containing object (re)using the functionality
  of the contained object(s)
• and thus avoiding implementing that behavior on
  its own
• Somewhat available in traditional procedural
  languages

58
Reusability Mechanisms - Composition

• class SSNum
• boolean equals(SSNum other)

class Employee boolean equals(Employee other)
return id.equals(other.id) SSNum id
59
Reusability Mechanisms - Delegation

• One object carries out a request by delegating it
  to a second object (typically an instance
  variable of the first)
• Used widely in the context of composition,
  especially as a way of obtaining some of the
  flavor of inheritance
• In the previous example, the Employee object
  delegated the equality test to the (composed)
  SSNum objects equals function.
• Somewhat available in traditional procedural
  languages

60
Reusability Mechanisms - Interfaces

• A set of function signatures (no bodies)
• No implementation the function signatures
  represent an abstraction of functionality
• Can be thought of as representing a type
• Can be specified in C via abstract classes and
  in Java via interfaces.
• A class (i.e., with function bodies) is said to
  implement the interface if the class defines
  (i.e., supplies bodies for) all the interfaces
  functions
• As with inheritance, the implementing class is
  also said to be a subtype of the interfaces type
• Not available in traditional procedural languages

61
Reusability Mechanisms - Interfaces

• interface Collection
• boolean add(Object obj)
• boolean remove(Object obj)
• int size()
• boolean isEmpty()

62
The Is-a Relationship

• An object of a subtype is compatible with the
  corresponding (parent) type.
• As well see, an object of the subtype can be
  assigned to a variable of the parent type
• The object of the subtype is considered an object
  of the type as well
• And can appear and be used anywhere the parent
  types objects can
• This is known as the is-a relationship
• An object of a subtype is-a object of the
  parent type as well
• and is the basis for much of the reusability of
  OOP

63
Is-a in the Context of Inheritance

• An object of a subclass is compatible with the
  parent class type
• Thus given a Counter variable, a BoundedCounter
  object can be assigned to that variable
• BoundedCounter bctr
• Counter ctr bctr
• The parent type (a superclass) is a concrete type
  with its own implemented behavior.

64
Is-a in the Context of Interface

• An object of a class implementing an interface is
  compatible with the interfaces type
• E.g., assume class HashSet implements the
  Collection interface. Then, given a Collection
  variable, a HashSet object can be assigned to
  that variable
• HashSet set
• Collection coll set
• The parent type in this situation is an
  abstraction. The only implemented behavior
  belongs to the subtype.

65
The Dynamic Nature of Type/Subtype Compatibility

• Given a variable of a parent type containing an
  object of the subtype
• Calling a function calls the subtype objects
  function!
• Set set
• collection coll set
• coll.add(Hello) // set insertion!
• This is known as

Polymorphism
66
So What???

• Given an interface, Collection, write a method,
  intersection that returns a set corresponding
  intersection of two specified collections.
• Set intersection(Collection coll1, Collection
  coll2)
• Set result new Set()
• for (Object element coll1)
• if (coll2.contains(element)) result.add(element)
  
• return result
• intersection can accept as parameters) Sets,
  Vectors, in fact any combination of class that
  implement the Collection interface.
• Only one intersection function need be written
  for a whole family of different aggregate classes
  all due to the polymorphism of the contains and
  add functions.
• This is reusability of a sort impossible to
  achieve with a procedural language

67
Describing Design Patterns

• Recall our Flywheel
• In addition to presenting the flywheel we also
  presented
• Motivation
• Purpose
• Application
• Advantages/disadvantages

68
Describing Design Patterns

• Design Patterns are presented in a similar
  (fairly standardized) fashion

69
Pattern Description - Name

• Name should be a good reflection of the patterns
  purpose
• Adapter

70
Pattern Description - Intent

• A statement answering
• What does the pattern do?
• What is its rationale?
• What problem does it address?
• Adapter converts the interface of a class into
  another interface clients expect. Adapter lets
  classes work together that otherwise couldnt
  because of incompatible interfaces

71
Pattern Description Also Known As

• Other names by which the pattern is known
• Wrapper

72
Pattern Description Motivation

• A scenario that illustrates the problem and its
  solution via the classes and structures of the
  pattern
• Our CIS 22/STL Stack problem and solution

73
Pattern Description Applicability

• Under what circumstances can the pattern be
  applied?
• What are examples of poor designs that the
  pattern can address?
• How can such situations be recognized?
• Use Adapter when
• You want to use an existing class and its
  interface does not match the one you need

74
Pattern Description Structure

• A graphical representation of the relationships
  among the classes/objects in the pattern

Client
Target Request()
Adaptee SpecificRequest()
Class Interface Implemented method() Abstract
method()
Adapter Request()
adaptee
adaptee.specificRequest()
Instance variable
subtype
75
Pattern Description Participants

• The classes and objects participating in the
  pattern
• Target (the interface consisting of push, pop,
  isEmpty)
• Defines the specific interface that Client uses
• Client (Your 22 program)
• Interacts with objects conforming to the Target
  interface
• Adaptee (STL stack type)
• Defines an existing interface that needs adapting
• Adapter (StackAdapter)
• Adapts the interface of Adaptee to the Target
  interface

76
Pattern Description Collaborations

• How the participants interact to realize the
  pattern
• Clients call operations on an Adapter object
• In turn the adapter calls Adaptee operations

77
Pattern Description Consequences

• What are the trade-offs and results of using the
  pattern?
• How much adapting does Adapter do?
• Simple name changes all the way to supporting
  completely different set of operations
• There are several other consequences we cant
  address here

78
Pattern Description Implementation

• Pitfalls, hints, techniques?
• Language-dependent issues?
• Fairly straightforward
• There are some language issues, but again, not
  for now

79
Pattern Description Sample code

• Well just let our example be the sample code

80
Pattern Description Known uses

• Examples from real systems
• Take a look at Gamma

81
Pattern Description Related Patterns

• What other patterns are closely related to this
  one?
• What are the similarities? Differences?
• Which patterns use this pattern?
• Which patterns does this pattern use?
• This was our first one!
• Too early to supply answers for this

82
Why are Design Patterns Useful?

• Avoids reinventing the wheel
• Avoids making the same mistakes over and over
  again
• Knowledge of a particular design pattern (like
  Adapter) is valuable
• but so is simply knowing about the concept of a
  design pattern
• Knowing there are catalogs of patterns addressing
  design issues
• Gets you thinking about design problems
  differently

83
Another Example

• Adapter was an example of a Structural design
  pattern
• Structural patterns are concerned with how
  classes and objects are composed to form larger
  structures.
• Our next example will present a Creational design
  pattern
• Creational patterns help make a system
  independent of how its objects are created and
  represented.

84
Another Example

• Us folks at
• Provide interactive programming exercises
• Students submit solution code to our server which
• Does operational and textual checks
• Provides feedback
• In addition, there is a context-sensitive
  glossary/help system
• Generates hypertext links into the glossary,
  on-the-fly, for instructions and feedback

85
Creating a Glossary Object

• Glossary glossary new Glossary()
• Issues
• Glossary is quite large one is OK, but what if
  there are tens (or hundreds) of concurrent users?
• No need for more than one glossary
• Its a query-only object

86
Creating a Glossary Object

• Is there a way to prevent more than one Glossary
  object from being created?
• The expression
• glossary new Glossary()
• creates a new instance each time
• And if we can restrict to one instnacnce, how
  does the rest of the application access that
  single instance?
• C could use a global variable.
• What about Java?

87
Singleton Design Pattern - Intent

• Ensure a class has only one instance and provide
  a global point of access to it

88
Singleton - Motivation

• Just gave it to you, but since you asked
• Ensuring single print spooler in a system
• Ensuring a single buffer/node pool

89
Singleton - Applicability

• Applicability
• Used when
• There must be exactly one instance, which must be
  accessible from a well-known point

90
Singleton - Structure
Singleton static instance() singletonOperation()
getSingletonData() static uniqueInstance singleto
nData
return uniqueInstance
91
Singleton - Participants

• Participants
• Singleton
• Defines an instance operation that allows clients
  to access its unique instance
• instance is a class function/method
• May be responsible for creating its own unique
  instance

92
Singleton - Collaborations

• Collaborations
• Clients access a Singleton instance solely
  through the instance operation

93
Singleton - Consequences

• Controlled access to single instance
• Reduced name space
• No global variables
• Permits variable number of instances
• I lied its actually one glossary per language
• glossary new Glossary(Java)

94
Singleton - Implementation

• class Glossary
• public static Glossary getGlossary()
• if (glossary null)
• glossary new Glossary()
• return glossary
• private Glossary()
• private Glossary glossary
• Note the private Glossary constructor

95
Behavioral Patterns

• Structural and creational patterns are two of the
  three pattern purposes, the third being
  behavioral patterns
• Behavioral patterns are concerned with
• algorithms
• the assignment of responsibilities between
  objects
• the patterns of communication between
  objects/classes
• characterize complex control flow
• Well now present Observer, a baehavioral pattern
  and in IMHO, one of the most beautiful patterns
  of all

96
This is not Your Fathers Oldsmobile

• On a typical mid-to-high-end car these days
• rain sensors turn on the wipers
• wipers turn on the lights
• shifting out of park turns on day running lights
• turning on radio raises antenna
• pressing brake disengages cruise control
• and a host of other interactions between
  sometimes seemingly unrelated components

97
One Particular Set of Interacting Components

• Lets focus on just three components
• The interior light
• The interior light switch
• Turning to on turns on the interior light
• The car door
• Opening turns on the interior light

98
Lets Code a Car Class

• class Car
• Door door new Door()
• InteriorLightSwitch interiorLightSwitch
• new InteriorLightSwitch()
• InteriorLight interiorLight new
  InteriorLight()

99
The InteriorLight Class

• class InteriorLight
• public boolean isOn() return amOn
• void setOn(boolean b)
• if (amOn ! b)
• amOn b
• System.err.println("interior light turned
  (amOn ? "on" "off"))
• boolean amOn false

100
The InteriorLightSwitch Class

• class InteriorLightSwitch
• public boolean isOn() return amOn
• void setOn(boolean b)
• if (amOn ! b)
• amOn b
• System.err.println("interior light switch
  moved to "
• (amOn ? "on" off"))
• interiorLight.setOn(amOn)
• boolean amOn false

101
The Door Class

• class Door
• public boolean isOpen() return amOpen
• void setOpen(boolean b)
• if (amOpen ! b)
• amOpen b
• System.err.println("door "
• (amOpen ? "opened" "closed"))
• interiorLight.setOn(amOpen)
• boolean amOpen false

102
Mind Your Own Business

• Door knows it should turn on light
• Interior switch knows it should turn on light
• An alarm module (keyless entry) would also have
  to turn on light
• Who should know when to
• turn on the interior light?

103
More Issues

• In luxury model opening door causes seat to
  slide back
• Now door must know to turn on light and slide
  seat back
• But what about non-luxury cars?
• Separate door mechanism for luxury/non-luxury?
• Luxury/non-luxury models wired differently?

104
Spaghetti Responsibility Logic

• Turning on wiper switch
• Must know to turn on wipers
• Wipers in turn must know to turn on headlights
  and activate 4WD sensor
• Headlights must know to dim radio display

105
Spaghetti Responsibility Logic

• Pressing brake
• Turns on upper rear brake light
• Turns on brake lights
• Disengages cruise control, but only if that
  option is present
• Initiates ALB sensor

106
Spaghetti Responsibility Logic

• Every component must know about all components
  dependent upon it
• Furthermore, every component becomes responsible
  for those components

107
Still Not Convinced??

• Well how about if I tell you that our
  implementation is wrong?

108
A Sample Car interaction

• public static void main(String args)
• Car car new Car()
• car.door.setOpen(true) System.err.println(car)
  
• car.door.setOpen(false) System.err.println(car)
  
• car.interiorLightSwitch.setOn(true)
  System.err.println(car)
• car.door.setOpen(true) System.err.println(car)
  
• car.door.setOpen(false) System.err.println(car)
  

109
The Output

• door opened
• interior light turned on
• door opened / interior light on / interior
  light switch off
• door closed
• interior light turned off
• door closed / interior light off / interior
  light switch off
• interior light switch moved to on
• interior light turned on
• door closed / interior light on / interior
  light switch on
• door opened
• door opened / interior light on / interior
  light switch on
• door closed
• interior light turned off
• door closed / interior light off / interior
  light switch on

110
OOP Responsibility-Driven Programming

• Goal is for objects (components) to be
  responsible for themselves
• Decoupling objects simplifies the design
• The simpler, more self-responsible objects are
  easier to reuse

111
The Observer Design Pattern - Intent

• Define a (many to one) dependency between objects
  so that when one object changes state, all its
  dependents are notified and updated automatically

112
Observer - Applicability

• Use Observer when either
• A change to one object requires changing others,
  and you dont know how many others need to be
  changed
• An object should be able to notify other objects
  without making assumptions about who those
  objects are (minimize coupling between the
  objects)

113
Observer - Structure
Subject attach(Observer) detach(Observer) notify(
)
observers
Observer update()
for (o in observers) o.update()
ConcreteObserver update() observerState()
subject
ConcreteSubject getState() subjectState
observerState subject.getState()
return subjectState
114
Applied to the Car Application
Subject attach(Observer) detach(Observer) notify(
)
observers
Observer update()
for (o in observers) o.update()
InteriorLight update()
Door isOpen() amOpen
setOn(door.isOpen() ilswitch.isOn())
return amOpen
InteriorLightSwitch isOn() amOn
return amOpen
115
Observer - Participants

• Subject
• Knows its observers. Any number of Observers may
  observe a Subject
• Provides an interface for attaching (registering)
  / detaching (unregistering) Observers
• Observer
• Defines an updating interface for objects that
  should be notified of changes in a Subject
• ConcreteSubject
• Stores state of interest to ConcreteObservers
• ConcreteObserver
• Implements Observers updating interface to be
  notified of changes to ConcreteSubject object

116
Observer - Collaboration

• ConcreteSubject notifies its observers when a
  change occurs
• After being notified, a ConcreteObserver may
  query the subject for more information

117
The Observer Interface

• interface Observer
• void update(Observable observable, Object arg)
• An Observers update method is called (by the
  observable object) when the observable object has
  changed. arg is an optional argument containing
  any additional useful information about the
  change.

118
The Observable Superclass

• class Observable
• void addObserver(Observer observer)
• observers.add(observer)
• void notifyObservers(Object arg)
• for (observer observers)
• observer.update(this, arg)
• void notifyObservers() notifyObservers(null)
• SetltObservergt observers new HashSetltObservergt()
  

119
The InteriorLight Class

• class InteriorLight implements Observer
• InteriorLight()
• interiorLightSwitch.addObserver(this)
• door.addObserver(this)
• public boolean isOn()
• private void setOn(boolean b)
• public void update(Observable observable,
  Object arg)
• setOn(interiorLightSwitch.isOn()
  door.isOpen())
• boolean amOn false

120
The InteriorLight Class

• class InteriorLight implements Observer
• InteriorLight()
• public boolean isOn() return amOn
• private void setOn(boolean b)
• if (amOn ! b)
• amOn b
• System.err.println("interior light turned "
  (amOn ? "on" "off"))
• public void update(Observable observable,
  Object arg)
• boolean amOn false

121
The InteriorLightSwitch Class

• class InteriorLightSwitch extends Observable
• public boolean isOn() return amOn
• void setOn(boolean b)
• if (amOn ! b)
• amOn b
• System.err.println("interior light switch
  moved to "
• (amOn ? "on" "off"))
• notifyObservers()
• boolean amOn false

122
The Door Class

• class Door extends Observable
• public boolean isOpen() return amOpen
• void setOpen(boolean b)
• if (amOpen ! b)
• amOpen b
• System.err.println("door "
• (amOpen ? "opened" "closed"))
• notifyObservers()
• boolean amOpen false

123
The Output This Time

• door opened
• interior light turned on
• door opened / interior light on / interior
  light switch off
• door closed
• interior light turned off
• door closed / interior light off / interior
  light switch off
• interior light switch moved to on
• interior light turned on
• door closed / interior light on / interior
  light switch on
• door opened
• door opened / interior light on / interior
  light switch on
• door closed
• door closed / interior light on / interior
  light switch on
• interior light switch moved to off
• interior light turned off
• door closed / interior light off / interior
  light switch off

124
Music Crescendoing to Climax

• Design patterns are pervasive
• Sometimes consciously employed
• Sometimes recognized only after the fact
• Some real manifestations

125
Minimizing Hard-coding

• The CodeLab engine can check exercises for any
  language that has a compiler
• An appropriate set of tools and entities
  compilers, linkers, compiler message analyzers,
  glossaries must be created specific to the
  language
• We want this done without hard-coding any
  knowledge of particular languages into the engine
• This is accomplished using the Factory Method
  pattern

126
Maintaining Consistency

• Furthermore, the language-specific tools used in
  an exercise must be consistent with each other
  (i.e., be restricted to tools of that specific
  language).
• This is addressed using the Abstract Factory
  pattern
• This design was introduced into the engine by
  Josh Goldsmith as part of his 88.1 project.

127
Invoking the Tools

• Many of the tools used to build and test
  exercises form tree-like hierarchies of sorts

Java Tool
C Tool
Java Compiler Tool
C Compiler Tool
Java Interpreter Tool
C Linker Tool
Executable Tool

• A Java Tool is executed by executing a Java
  Compiler Tool followed by executing a Java
  Interpreter Tool
• Similarly for the C Tool

128
Treating Individual Objects and Compositions
Identically

• Sometimes a full Java Tool is launched
• Other times simply the Java Compiler Tool
• We want to launch and subsequently process both
  tools (the composite Java Tool and the atomic
  Java Compiler Tool) identically
• This is achieved using the Composite pattern

129
Filtering Streams

• When processing submissions and exercise output,
  we often want to
• Remove whitespace completely
• Remove a final trailing linefeed
• Compress multiple whitespace to a single
  whitespace
• Remove comments
• Ignore case
• This is done using the Strategy pattern

130
Iteration

• Any class implementing the Collection interface
  must supply a uniform means of iterating over its
  elements.
• This is done via the Iterator pattern

131
Whew!

• In summary
• Design patterns provide highly flexible, reusable
  solutions to commonly arising design situations
• Patterns are recognized as valuable repositories
  of information based upon analysis and experience
• Catalogs exist enumerating collections of
  patterns
• Conscious use of patterns is widespread

132
Further Reading

• Design Patterns, Gamma, Helm, Johnson, Vlissides,
  Addison-Wesley, 1995
• Object-Oriented Design and Patterns, Horstman,
  Wiley, 2006
• Design Patterns Java Workbook, Metsker,
  Addison-Wesley, 2002
• The Design Patterns Java Companion, Cooper,
  http//www.patterndepot.com/put/8/JavaPatterns.htm