Design Patterns

Alan Shalloway, James Trott, Design Patterns Explained, Addison-Wesley, 2002.

Gamma, Helm, Johnson, Vlissides, Design Patterns, Elements of Reusable Object-Oriented

Software, Addison-Wesley, 1995.

Perspectives in software development:

• Conceptual: represent concepts. Ignore how software implements it. (SRS)

• Specification: look at the software interfaces, not at the implementation

• Implementation: write code

Design Pattern

• Describes– problem that occurs repeatedly– the core of the solution to that problem

• Solution can be reused – not necessary to implement it the same way

Where do you see Design Patterns?

• Seminars and conferences.

• Technical journals.

• Text books and trade journals.

• You don’t really know OO until you understand these.

• They may help you understand OO better.

Where did they come from?

Patterns start with a premise and answer two questions:– Premise: the goodness of a design is objective:

not entirely in the eyes of the beholder.– Q1: What is present in good designs that is not

present in poor ones?– Q2: What is present in poor designs that is not

present in good ones?

Pattern: A solution to a problem in a context

• Name– Becomes part of our vocabulary

– Allows abstract discussion of problem and approaches

– Allows discussion of issues instead of implementation

• Purpose– Description of the desirable thing

– Problems that prevent the desirable solution explicitly described

Vocabulary Example: find number in sorted list

• Find middle value and compare value we are looking for to that one. If found, we’re done. Otherwise, if we are looking for something bigger, set the new bottom to the current middle. Otherwise, set the new top to the current middle.

• Repeat the above step until the list can’t be divided further. If it’s not in the last two positions, it’s not in the list.

Example 2: find number in sorted list

• Use binary search.

Example 2: find number in sorted list

• Use binary search.

• This assumes that you know what binary search is.

• But if you know what binary search is, the discussion is greatly simplified.

• Algorithms are not patterns. This is an analogy.

Description of patterns:

• Name• Intent• Problem• Solution how does the pattern solve the problem• Participants • Consequences investigate forces at play• Implementation Note: this is not the pattern itself.• References (GoF?)

Elements

• Pattern name

• Problem– Explains the problem and its context– may include a list of conditions needed before

application of solution makes sense

• Solution

• Consequences

Elements

• Pattern name• Problem• Solution

– Describes elements of design, relationships, responsibilities, and collaborations

– Does not describe a particular implementation

– Abstract description and how a general arrangements of objects solves problem

• Consequences

Elements

• Pattern name

• Problem

• Solution

• Consequences– Results and trade-offs of applying pattern– Needed to evaluate tradeoffs between solutions– Frequently time/space trade-offs

Why patterns?

• Reuse existing, high-quality solutions to common problems– incorporates a great deal of

experience– may describe things often

overlooked or subtle that prevent good solutions

Why patterns?

• Reuse existing, high-quality solutions to common problems– incorporates a great deal of experience– may describe things often overlooked or subtle that

prevent good solutions

• Focus on issues not implementation– Shift thinking to higher level – Decide if design is right, not just working– Learn how to design– Improve code: smaller hierarchies, more modifiable code.

Strategies suggested by patterns

1. Design to interfaces

Strategies suggested by patterns

1. Design to interfaces

2. Favor composition over inheritance

Strategies suggested by patterns

1. Design to interfaces2. Favor composition over inheritance3. Find what varies and encapsulate it.

• Consider what should vary in your design.• Consider what you want to be able to change

without redesign (as opposed to what might force you to redesign)

• Encapsulate this

Catalog of Patterns

• GOF = “Gang of four” (1995)– Erich Gamma– Richard Helm– Ralph Johnson– John Vlissides

• 23 patterns

• Others since then

GOF: 23 Patterns

• Abstract Factory• Adapter• Bridge• Builder• Chain of

Responsibility• Command• Composite

• Decorator• Facade• Factory Method• Flyweight• Interpreter• Iterator• Mediator• Memento

• Observer• Prototype• Proxy• Singleton• State• Strategy• Template

Method• Visitor

Design Pattern Classification

• We classify design patterns by two criteria:– Purpose: Reflects what the Pattern does.

– Scope: Specifies whether the pattern applies primarily to classes or to objects.

Design Pattern Purposes

• Patterns can have either creational, structural, or behavioral purpose.– Creational patterns: concern the process of

object creation. – Structural patterns: deal with the composition of

classes or objects. – Behavioral patterns: characterize the ways in

which classes or objects interact and distribute responsibility.

Design Patterns Scopes • Class patterns deal with relationships

between classes and their subclasses. – These relationships are established through

inheritance, so they are static—fixed at compile-time.

• Object patterns deal with object relationships, which can be changed at run-time and are more dynamic.

In General

• Almost all patterns use inheritance to some extent.

• The only patterns labeled "class patterns" are those that focus on class relationships.

• Note that most patterns are in the Object scope.

Solving Problems

• Patterns help you identify non-obvious abstractions– e. g. Strategy describes pattern for

interchangeable families of algorithms

• Patterns can guide decisions about what is an object

How to Select a Design Pattern

• Consider how design patterns solve design problems

• Scan Intent sections

• Study how patterns interrelate and patterns of like purpose

• Consider what should be variable in your design

How to use a pattern

• Read the pattern paying attention to Applicability and Consequences

• Study the Structure, Participants, and Collaborations

• Look at Sample Code• Choose good names for participants• Define the classes, interfaces, and operations• Implement the operations to carry out the

responsibilities and collaborations

GOF Design Patterns App

• Android for $.99

• Take a look at it… might be helpful for exam and/or project

Design Patterns: Model-View Separation

Motivation:

• Suppose you have a system that needs to run on a variety of devices– Maybe a cell phone and a PDA– Maybe Windows and with a command line– . . .

Motivation:

• Suppose we support both the command line and the GUI interfaces.

• What changes?

• What stays the same?

Motivation:

• Suppose we support both the command line and the GUI interfaces.

• What changes?

• What stays the same?

• How do you design to handle this?

Model-View Separation Pattern

• Model: The domain layer of objects. (objects that contain data and operations).

• View: The presentation layer of objects (windows, applets, reports).

Model-View Context

• Context/Problem– It is desirable to:

• de-couple domain (model) objects from windows (views)

• support increased reuse of domain objects• minimize the impact of changes in the

interface upon domain objects

Model-View Context

• Context/ProblemIt is desirable to de-couple domain (model) objects from windows (views), to support increased reuse of domain objects, and minimize the impact of changes in the interface upon domain objects.

• SolutionDefine the domain (model) classes so that they do not have direct coupling or visibility into the window (view) classes, and so that application data and functionality is maintained in domain classes, not window classes.

Model-View

Window

Configuration

display( )

addEntry( )query( )

Model

View

Goal: Classes in Model should not have direct visibility to classes in View.

Model-View Separation Motivation

Motivation• Focus more on the domain processes rather than

on computer interfaces.• Allow separate development of the model and user

interface layers.• Minimize the impact of changes in the interface

upon the domain layer.• Allow new views to be easily connected to an

existing domain layer.

Problem

Window

Configuration

display( )

addEntry( )query( )

Model

ViewModel classes talk to View classes.

Worse

displayMessage ( )

Model-View Separation Pattern

Window

Configuration

display( )

addEntry( )query( )

Model

View

query( )

View classes talk to Model classes.

Better

Model-View Separation Pattern

Configuration

Old Window

display( )

addEntry( )query( )

Model

View

query( )

New Window

display( )

The View Layer can be modified without affecting the Model layer.

Model-View Separation Pattern

Configuration

addEntry( )query( )

Model

View

query( )

New Window

display( )

When the Window needs to display data it queries the Model objects “Polling Model”

Model-View Separation Pattern

• Problem: Domain objects need to communicate with windows to cause a real-time ongoing display update as the state of information in the domain object changes.- Monitoring applications- Simulation applications

• Solution: Indirect Visibility

Model-View Separation Pattern with Indirect Visibility

• Named Publish-Subscribe Pattern• Context/Problem:

A change in state (an event) occurs within a Publisher of the event and other objects are dependant on or interested in this event (Subscribers to the event). The Publisher should not have direct knowledge of its subscribers.

• Solution:Define an event notification system so that the Publisher an indirectly notify Subscribers. Event Manager or Model View Controller (MVC).

Model-View Separation Pattern with Indirect Visibility

http://gmoeck.github.com/2011/03/10/sproutcore-mvc-vs-rails-mvc.html

Model-View Separation Pattern with Indirect Visibility

Design Patterns:Façade

Façade

• Intent: want to simplify the use of an existing system. Need to define an interface that is a subset of the existing one.

• Problem: – You only need a subset of a complex system or need to

interact in a particular way. – The API for the subset is simpler than the API for the

entire subsystem. – You may want to hide the original system, or you may

want to use a subset of the system and add functionality.

Façade

• Solution: The façade presents a new interface• Participants: presents a specialized interface to

the client to make it easier to use• Consequences:

– Simplifies the use of the subsystem. – Some functionality may not be available to the client.

• Implementation: – Define a new class (or classes) that has the required

interface. – Have this class use the existing system.

Façade Example

• Huge database interface, but we only need a few of the functions.

• Rather than everyone learning the database interface, create the interface you need, and build a façade.

Without Façade

ClientA Database

ClientB

Element

Model

With Façade

ClientA

Database

ClientB

Element

ModelDBFacade

Other Patterns of Interest• State Design Pattern

• Strategy Design Pattern

• Singleton Design Pattern

• Adapter Design Pattern