The document covers design patterns in software development, discussing their history, classification, structure, and principles such as the open-closed principle and loosely coupled design. Specific patterns like the observer and factory patterns are highlighted, along with examples of their implementation and use cases. The importance of clear naming and the challenges of ambiguity in pattern vocabulary are also emphasized.

1. Lecture 05
Design Patterns

2. Agenda
 Patterns
– History, classification, structure
 Design Principles
– Loosley Coupled Design Principle
– Open-Close Principle
 Base Patterns

3. Reading
 Design Patterns
 Observer pattern
 Factory pattern
 Base Patterns
 The Open-Closed Principle

4. Patterns

5. Design Patterns
 Design pattern is a general solution to a common
problem in software design
– Systematic approach for problems that reoccur in software
development
– Not complete solution but starting point for design
– Not code ready to use
– Patterns have names and definitions
– Built on common practices
 Patterns should not be language dependant
– However patterns apply for types of programming
languages

6. History
 Patterns originated as an architectural concept
“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”
- Christopher Alexander

7. History
 Landmark book from 1995:Design Patterns:
Elements of Reusable Object-Oriented Software
– Gang of Four (GoF)
– Term Design Pattern is
borrowed from the
construction industry
 Several books on patterns
have been published since
– Head First Design Patterns
for example

8. Vintage Design Patterns
 Design Patterns are like good red wine
– You cannot appreciate them at first
– As you study them you learn the
difference between plonk and vintage,
or bad and good designs
– As you become a connoisseur you experience the
various textures you didn’t notice before
 Warning:
– Once you are hooked, you will no longer be satisfied
with inferior designs
Dr. Heinz Kabutz (http://www.javaspecialists.co.za)

9. Pattern Classification
 Design patterns can be classified based on
multiple criteria
– Basic underlying problem they solve
 Classification
– Fundamental patterns
– Creational patterns
– Structural patterns
– Behavioral patterns
– Concurrency patterns

10. Enterprise Patterns Classification
 Domain Logic Patterns
 Data Source Architectural Patterns
 Object-Relational Behavioral Patterns
 Object-Relational Structural Patterns
 Object-Relational Metadata Mapping Patterns
 Web Presentation Patterns
 Distribution Patterns
 Offline Concurrency Patterns
 Session State Patterns
 Base Patterns

11. QUIZ
Which of these statements is not true
A) Design Patterns are based on solutions from practice
B) Design Patterns are ideas not code
C) Design Patterns are based on specific programming languages
D) Design Patterns can have ambiguous names

12. QUIZ
Which of these statements is not true
A) Design Patterns are based on solutions from practice
B) Design Patterns are ideas not code
C) Design Patterns are based on specific programming languages
D) Design Patterns can have ambiguous names
✔

13. Structure of Patterns

14. Structure of Patterns
 Name
 The Intent
 The Sketch
 Motivation
 How it Works
 When to Use it
 Further Reading
 Examples

15. The Name
 Pattern names are important
– Need to create a vocabulary
– Need to describe the pattern well
– Avoid ambiguity and misunderstanding
 Problems with names
– Authors are using different names for same pattern
• Data Access Object and Table Data Gateway
• Dependency Injection and Inversion of Control
– Authors are using same name for different patterns
• Example: Value Object is used for two similar patterns

16. The Intent
 Sums up the pattern in a sentence or two
– Value Object:
A small simple object, like money or date range, whose
equality isn’t based on identity

17. The Sketch
 Visual representation of the pattern, often but
not always a UML diagram

18. Motivation
 Description of a motivating problem for the
pattern
– Problem description
– May not be the only problem for the pattern
 Example:
– Layered supertype
It’s not uncommon for all the objects in a layer to have
methods you don’t want to have duplicated
throughout the system. You can move this behavior
into a common Layer Supertype

19. How it Works
 Describes the solution
– Implementation Issues
– Variations
– Independent of any particular platform
– Platform dependent sections are identified
– UML Diagrams if applicable
 Plugin example

20. When to Use It
 Describes when the pattern should be used
– Trade-offs
– Comparisons
 Layered Supertype example
– Use Layer Supertype when you have common
features from all objects in a layer

21. Examples
 Example code in Java or C#
– Layer Supertype
 Not working code
– pseudo code to give idea
class DomainObject...
private Long ID;
public Long getID()
{
return ID;
}
public void setID(Long ID)
{
this.ID = ID;
}
public DomainObject(Long ID)
{
this.ID = ID;
}

22. Using Design Patterns
 How to use design patterns?
– Problem is the patterns can be complex and detailed
– Usually they are generic and abstract
 Ways to study patterns
– Implement them in test code
– Sketch a class diagram in your context to see the
class dependencies
– Form a “Study group” to discuss the patterns
– Learn the vocabulary
– Practice, practice, practice

23. Problems with Patterns
 Ambiguity in Vocabulary
– Same pattern has different names
– Different Patterns have same name
 Appling the wrong pattern
– Over-designing the solution
– Patterns design for one language might not be
needed in another
 Not solving the original problem
– Using Remote Façade instead of avoiding network
latencies
– Using EJB Entity Beans

24. EXERCISE
Job interview question
You are given the assignment of creating a component that needs to
know sales statistics of Lottery tickets. You know that there is a
another component in the system, Sale Server, that handles the sale.
You need real-time information. What would you suggest?

25. First proposal: Sale Server will call Bingo
Sale server Bingo
Problem is that the Sale Server developer refuses to make a call to
a specific game. His argument is that Sale Server should be for
sale, and not be cluttered with game specific code.
Another solution is needed.

27. registerObserver
Sale server notify
Bingo

28. The Observer Pattern

29. The Weather Monitoring Example
 The Weather Monitoring application

30. The Weather Monitoring Example
 Task
– We need to implement measurementsChanged so
that it updates three different displays for current
conditions, weather stats, and forcasts
– measurementsChanged is called any time data
changes, we don’t know or care how this method is
called
– Three display types must be updated
– The system must be expandable – new display types
will be added

31. The Weather Monitoring Example
 WeatherData class
public class WeatherData
{
// instance variable declarations
public void measurementsChanged()
{
float temp = getTemperature();
float humidity = getHumidity();
float pressure = getPressure();
currentConditionsDisplay.update (temp, humidity, pressure);
statisticsDisplay.update (temp, humidity, pressure);
forcastConditionsDisplay.update (temp, humidity, pressure);
}
...
}

32. QUIZ
 Based on our first implementation, which of the
following apply
A. We are coding to concrete implementation not
abstractions
B. For every new display element we need to alter code
C. We have no way to add (or remove) display elements at
runtime
D. The display elements don’t implement a common
interface
E. We have not encapsulated the part that changes
F. We are violating encapsulation of the WeatherData
class

33. The Weather Monitoring Example
 WeatherData class
public class WeatherData
{
// instance variable declarations
public void measurementsChanged()
{
float temp = getTemperature();
float humidity = getHumidity();
float pressure = getPressure();
Interface is that same for
all
currentConditionsDisplay.update (temp, humidity, pressure);
statisticsDisplay.update (temp, humidity, pressure);
forcastConditionsDisplay.update (temp, humidity, pressure);
}
...
}
By coding to concreate implementation
we have no way to add or remove
displays without code change

34. Observer
One or more observers or listeners are registered to
observe an event which may be raised by the
observed object (the subject)
 Sometimes called publish/subscribe
– Similar to call-back handlers
– One-to-Many relationship
 Benefits
– Listening object gets information when needed
– Subject does not become dependent on multiple observers

35. Observer Design Pattern

36. Observer Design Pattern
 Subject does not depend on listeners

37. Loose Coupling
 When two object are loosley coupled, the can
interact but they have very little knowledge of each
other
 The Observer Pattern loosley coupled design
– The only thing the subject knows about observer is that it
implements a ceratain interface
– We can add new observers at any time
– We never need to modify the subject to add new types of
observers
– We can reuse subjects or observers independent of each
other

38. Loosley Coupled Principle
Strive for loosely coupled
designs between objects
that interact

39. Weather Station Example
public interface Subject
{
public void registerObserver(Observer o);
public void removeObserver(Observer o);
public void notifyObservers();
}
public interface Observer
{
public void update(float temp, float humidity, float pressure);
public interface DisplayElement
{
public void display();
}
}

40. Weather Station Example
public class WeatherData implements Subject
{
private ArrayList observers;
private float temperature, humidity, pressure;
public WeatherData()
{
observers = new ArrayList();
}
public void registerObserver(Observer o)
{
observers.add(o);
}
public void removeObserver(Observer o)
{
int i = observers.indexOf(o);
if (i>= 0)
observers.remove(i);
}

41. Weather Station Example
public void notifyObservers()
{
for (int i = 0; i<observers.size(); i++) {
Observer observer = (Observer)observers.get(i);
observer.update(temperature, humidity, pressure);
}
}
public void measurementsChanged()
{
notifyObservers();
}
// Test code
public void setMeasurement(float temperature, float humidity,
float pressure) {
this.temperature = temperature;
this.humidity = humidity;
this.pressure = pressure;
this.measurementsChanged();
}

42. Weather Station Example
public class CurrentConditionsDisplay implements Observer,
DisplayElement
{
private float temperature, humidity;
private Subject weatherData;
public CurrentConditionsDisplay(Subject weatherData) {
this.weatherData = weatherData;
weatherData.registerObserver(this);
}
public void update(float temp, float humidity, float pressure) {
this.temperature = temp;
this.humidity = humidity;
display();
}
public void display() {
System.out.println("Current conditions: " + temperature + "C " +
"Humidity: " + humidity + "%");
}
}
Registering
this as an
observer
The subject
will call
update

43. Weather Station Example
public class WeatherStation
{
public static void main(String[] args)
{
WeatherData weatherData = new WeatherData();
CurrentConditionsDisplay currentDisplay = new
CurrentConditionsDisplay(weatherData);
weatherData.setMeasurement(15, 50, 30);
}
}
Current conditions: 15.0C Humidity: 50.0%

44. Loose Coupling
 When two object are loosley coupled, the can
interact but they have very little knowledge of each
other
 The Observer Pattern loosley coupled design
– The only thing the subject knows about observer is that it
implements a ceratain interface
– We can add new observers at any time
– We never need to modify the subject to add new types of
observers
– We can reuse subjects or observers independent of each
other

45. Loosley Coupled Principle
Strive for loosely coupled
designs between objects
that interact

46. The Open-Closed Principle

47. The Open-Closed Principle
Software entities like
classes, modules and
functions should be open for
extension but closed for
modifications

48. The Open-Closed Principle
 Design and write code in a fashion that adding
new functionality would involve minimal changes
to existing code
– Most changes will be handled as new methods and
new classes
– Designs following this principle would result in
resilient code which does not break on addition of
new functionality

49. Resource Allocator Example
public class ResourceAllocator
{
...
public int allocate(intresourceType)
{
intresourceId;
switch (resourceType)
{
case TIME_SLOT:
resourceId = findFreeTimeSlot();
markTimeslotBusy(resourceId);
break;
case SPACE_SLOT:
resourceId = findFreeSpaceSlot();
markSpaceSlotBusy(resourceId);
break;
...
}
return resourceId;
}
...
Holy Buckets!!
I need to change
the class for new
types!!! Horrible!

50. Resource Allocator Example
 Design for extensions
List resources = new ArrayList();
...
public int allocate(intresourceType)
{
int resourceId = findFreeResource(resourceType);
markAsBusy(resourceId);
return resourceId;
}

51. Another Example
protected String normalize(char cCharacter)
{
switch(cCharacter) {
case '<': return "&lt;";
case '>': return "&gt;";
case '&’: return "&amp;";
case '"’: return "&quot;";
default: return ""+cCharacter;
} }
What is wrong with
this code?
 This is not complete
 This is common problem – a library must exists
 If making it yourself, a Map would be better

52. Callback Handlers

53. Task
We need to create program that reads feeds
Feed can be RSS news, XML or what ever
The program must be loosely coupled
New feed types will come

54. Creating Objects
 Where does the creation take place?
Enterprise Application
This stays the same
This that is added

55. Call-back Handlers
 Inverting the Dependency
– Let a class call you back
ReaderProcess RssFeedReader
processEntry
processEntry
processEntry
 Example
– sort routine, reading records
Read

56. Example: Reading RSS
 Process to read an RSS feed
– The FeedReader define the role of such readers
– Concrete readers must implement read and accept a
call-back handler to get the results back
public interface FeedReader
{
public boolean read();
public void setFeedHandler(FeedHandler handler);
}
public interface FeedHandler
{
public void processEntry(FeedEntry entry);
}

57. Example: Reading RSS
 AbstractFeedReader acts as a superclass for
concrete reader classes
– Layered Supertype pattern
public abstract class AbstractFeedReader implements FeedReader
{
protected FeedHandler feedHandler;
public void setFeedHandler(FeedHandler handler)
{
this.feedHandler = handler;
}
public abstract boolean read();
}

58. Example: Reading RSS
 RssFeedReader
public class RssFeedReader extends AbstractFeedReader
{
private String source;
public RssFeedReader(String source)
{
this.source = source;
}
public boolean read()
{
// reading ...
feedHandler.processEntry(new FeedEntry(ent.getTitle(),
ent.getLink(), ent.getPublishedDate().toString()));
}
return true;
}
}

59. Example: Reading RSS
 ReaderProcess is the client
public class ReaderProcess implements FeedHandler
{
FeedReader reader;
public ReaderProcess()
{
ReaderFactory factory = ReaderFactory.getReaderFactory();
reader = factory.getFeedReader("http://...");
reader.setFeedHandler(this);
}
public void processEntry(FeedEntry entry)
{
...
}
}

60. Example: Reading RSS

61. Call-back Handlers
 Inverting the Dependency
– Let a class call you back
ReaderProcess RssFeedReader
processEntry
processEntry
processEntry
 Example
– sort routine, reading records
Read

62. Factory

63. The Problem with “new”
 new is used to create object
 Problem is this:
– Even if we use supertypes (interfaces or abstract
classes) we have to have concrete class behind it
Animal animal = new Dog();
animal.makeSound();
– This violates the Program to Interfaces Design
Principle
– The code also violates the Open Closed Principle

64. Program to an interfaces
 Dependency Injection
– Make the caller responsible for setting the dependency
private Animal animal;
public setAnimal(Animal animal)
{
this.animal = animal;
}
...
animal.makeSound();
Injection happens
here, in the
set-method
LOOSE COUPLING = BEAUTIFUL!

65. Program to unknown creation
 What does this mean?
Animal animal = getAnimal();
animal.makeSound();
Where is this
getAnimal
coming from?

66. FeedReader
 Objects are created with new
public class ReaderProcess
{
FeedReader reader;
public ReaderProcess()
{
reader = new RssFeedReader
("http://www.mbl.is/mm/rss/togt.xml");
}
Holy Cow!
new creates
concrete object
not abstraction!!

67. FeedReader
 We need to have diffrent types
public ReaderProcess(String type, String source)
{
if(type.equals("rss"))
reader = new RssFeedReader(source);
else if (type.equals("atom"))
reader = new AtomFeedReader(source);
else if (type.equals("xml"))
reader = new XmlFeedReader(source);
reader.setFeedHandler(this);
}
Holy Macaroni!
This smells!!!
Violates the OCP

68. Moving the Dependency
 The name of the class is put in to a properties
file
– ReaderFactory has no clue of what class it is
pu–bliIct sjutastitc hFeaesdR etaode rbege taFe esdRueabdcerl(a)ss of FeedReader
{
FeedProperties prop = new FeedProperties();
Class instanceClass;
FeedReader reader = null;
try {
instanceClass = Class.forName(prop.getProperty("reader"));
reader = (FeedReader)instanceClass.newInstance();
}
catch (Exception e) {
System.out.println("loading class failed");
return null;
}
reader.setSource(prop.getSource());
return reader;
}
Plugin pattern

69. Loading Properties
 Properties class
public class FeedProperties extends Properties
{
protected String reader;
protected String source;
protected String DEFAULT_PROPERTIES = "feeds.properties";
public FeedProperties()
{
try {
load(new FileInputStream(new File(DEFAULT_PROPERTIES)));
reader = getProperty("reader");
source = getProperty("source");
}
catch (Exception e) {
System.out.println("Loading properties failed");
}
}
feeds.properties
reader=is.ru.honn.feeds.rss.RssFeedReader
source=http://www.mbl.is/mm/rss/togt.xml

70. Base Patterns

71. Base Patterns
 Gateway
 Mapper
 Layer Supertype
 Separated Interface
 Registry
 Value Object
 Plugin
 Service Stub

72.  Fowler’s Catalog
http://martinfowler.com/eaaCatalog/

73. Gateway (466)
An object that encapsulates access to an external
system or resource
 Wrap external APIs into an interface
– API is usually for accessing some external resource
• Examples: JDBC, JDom, financial software

74. Gateway (466)
 How It Works
– Create a simple API and use it access the external
API through a Gateway
– All access is easily defined
– Change in the resource does not require changes in
the client software
– Gateways should be simple – complex logic should
not be in the clients of the Gateway
– Gateways can be generated

75. Gateway (466)
 When to Use It
– Gateway is useful when accessing external service
– Can be applied with Service Stub (504)
– Clear benefit is that is makes it easy to swap out one
kind of resource for another

76. Mapper (473)
An object that sets up communiction between
two independent objects
 Create communication between two systems but
you still need to make them independent

77. Mapper (473)
 How it Works
– A Mapper is an insulating layer between subsystems
– It controls the details of communication between them
without either subsystem being aware of it
– Mappers are fairly easy as they are well-defined
– The tricky part is what system invokes them – third
party system or make the Mapper an Observer
 When to Use it
– When you want to decouple different parts of a
system

78. Layer Supertype (475)
A type that acts as the supertype
for all types in its layer
 Super class that contains common functionality
in a layer
 How it works
– Use this pattern when you
have common features
from all objects in a layer

79. Layer Supertype (475)
 When to use it
– When you have common features from all objects in a
layer.
 Example
– Domain objects can
have a common
superclass for
ID handling
class DomainObject...
private Long ID;
public Long getID()
{
return ID;
}
public void setID(Long ID)
{
this.ID = ID;
}
public DomainObject(Long ID)
{
this.ID = ID;
}

80. Example: Drawing system
 Shape class revisited
public abstract class Shape implements Drawable
{
protected int x,y;
}
– All objects in the drawing layer must have an origin (x
and y) and implement Drawable

81. Separated Interface (476)
Defines an interface in a separate
package from its implementation
 Decouples parts of a system
– Controls the dependencies between packages
– Implementation can easily be changed
 How it works
– Interface and implementation is placed in separate
packages
– Client uses the interface
– Implementation can be determined at configuration
time

82. Separated Interface
 Layered System
– Domain layer depends on Data Source layer
– Data Source layer cannot access Domain layer
Domain Layer
Data Source Layer
JDBC
Code
Concreate class
RowCallBackHandler
processRow(ResultSet rs)
Interface
RowCallBackHandler
processRow(ResultSet rs)
implements
Code reading SQL
Execution calls
Separated interface

83. Separated Interface (476)
 Implementation is placed in a separate package
Developers of the client
package are responsible for
the interface

84. Separated Interface (476)

85. Separated Interface (476)
 Instantiating the implementation
– User of the interface should not know the
implementation
 Solutions
– Use a Factory and Plugin method
– Use Dependency Injection

86. Separated Interface (476)
public interface FeedHandler
{
public void processObject (FeedEntry entry);
}
public class ReaderClient implements FeedHandler
{
...
public ReaderClient()
{
FeedReader reader = ReaderFactory.getFeedReader();
reader.setFeedHandler(this);
reader.read("http://rss.news.yahoo.com/rss/tech");
}
public void processObject(FeedEntry entry)
{
System.out.println(entry);
}
}
Callback

87. Registry (480)
A well-known object that other objects can use
to find common objects and services
 A registry is a global object
 How It Works
– Object that can easily be accessed at any time
– Only one object available at any time
– Provides services or information
– Can have different scopes
– Usually not mutable data
– Example: System Settings, Loggers

88. Singleton Registry (480)
 Only one instance running
public class Registry
{
private static Registry soleInstance = new Registry();
public static Registry getInstance()
{
return soleInstance;
 When to Use It
– As a last resort
}
private Registry()
{
}
...
}
Registry registry = Registry.getInstance();
//registry = new Registry (); Does not work

89. Value Object (486)
A small simple object, like money or date
range, whose equality isn’t based on identity
 Small and easily created objects that hold and
represent some data
 How it works
– Not based on identity
– Equality is based on comparing values of the object
– Can be immutable (example is the Date class)
 When to use it
– When you’re basing equality on something other than
identify

90. Value Object (486)
 Examples
– Date, Money
class Money...
private long amount;
private Currency currency;
public Money(double amount, Currency currency)
{
this.currency = currency;
this.amount = Math.round(amount * centFactor());
}
...

91. Value Object Example: Date
GregorianCalendar cal = new GregorianCalendar();
cal.set(1865, Calendar.APRIL, 14);
Date d1 = cal.getTime();
cal.set(1963, Calendar.NOVEMBER, 22);
Date d2 = cal.getTime();
System.out.println(d1.equals(d2));
cal.set(1756, Calendar.JANUARY, 27);
Date d3 = cal.getTime();
Date d4 = cal.getTime();
System.out.println(d3.equals(d4));
false
true

92. Plugin (499)
Links classes during configuration
rather than compilation
 Use plugin to provide specific implantation
– Plugins implement specific interface use by the client
application code
– Decision at configuration time or run time
– Use factory to load in the plugin
– For example: on plugin for test, another for production

93. Plugin (499)
 A caller obtains a Plugin implementation of a
caller a plugin factory a plugin configuration
getPlugin
lookupPluginByType
new
a plugin
separated interface
 When to Use It
– Use plugin when you have behavior that requires
different implementations based on runtime
environment

94. Plugin (499)
 ReaderClient uses ReaderFactory to get an
interface to FeedReader
ReaderClient ReaderFactory reader.properties
getFeedReader
props.getProperty("reader")
 reader.properties define the name of the actual
implementation class
new
FeedReader

95. Plugin (499)
public ReaderClient()
{
FeedReader reader = ReaderFactory.getFeedReader();
...
} public class ReaderFactory
{
public static FeedReader getFeedReader()
{
...
try
{
props.load(new FileInputStream(new File("reader.properties")));
instanceClass = Class.forName(props.getProperty("reader"));
reader = (FeedReader)instanceClass.newInstance();
} ...
return reader;
}
} reader=RssFeedReader

96. Service Stub (504)
Removes dependence upon problematic
services during testing
 Enterprise systems often need to access
external system
– Can be out of developers control

97. Service Stub (504)
 Service stub provides implementation for
development and testing purposes
– Runs locally and in-memory
– Implements the same interface of the gateway used
to access the real service
 When to Use It
– Service stub is useful when dependence on a
particular service is hindering development or testing
– Called “Mock Object” in the extreme programming
world

98. Service Stub Examples
public class ReaderStub extends AbstractFeedReader
{
public void read(String url)
{
feedHandler.processEntry(new FeedEntry("title1", "Bla bla bla"));
feedHandler.processEntry(new FeedEntry("title2", "Bla bla bla"));
feedHandler.processEntry(new FeedEntry("title3", "Bla bla bla"));
}
}
title1
Bla bla bla
title2
Bla bla bla
title3
Bla bla bla
reader.properties
reader=ReaderStub

99. Summary
 Base Patterns
– Gateway, Mapper, Layerd Supertype, Separated
Interface, Registry, Value Object, Plugin, Service
Stub, Record Set
 Next: From Problem to Patterns
– Using design patterns

100. QUIZ

101. Question #1
 You use this patterns when you need to break
a dependency between two parts of the
system
A) Registry
B) Gateway
C) Separated Interface
D) Plugin

102. Question #2
 Intent of a pattern is this: An object that sets
up communication between two objects
A) Gateway
B) Mapper
C) Registry
D) Value Object

103. Question #3
 Sketch of a pattern is his
A) Plugin
B) Mapper
C) Registry
D) Service Stub

104. Question #4
 Use this pattern when you find that dependence
on a particular service is hindering your
development and testing
A) Mapper
B) Record Set
C) Service Stub
D) Gateway

105. Next
 Using Design Patterns