Design Patterns

Reading 1

Object Oriented Design and Patterns

Chapter 5: Patterns and GUI Programming

5.1. Iterator as a Pattern

5.2. The Pattern Concept

5.3. The OBSERVER Pattern

5.4. Layout Managers...

5.5. Components, Containers,...

5.6. Scroll Bars and DECORATOR

5.7. How to Recognize Patterns

5.8. Putting Patterns to Work

This reading is required and will be covered on

quizzes and exams

Reading 2

Game Programming Patterns

Introduction

Architecture, Performance, and Games

Design Patterns Revisited Command

This reading is required and will be covered on

quizzes and exams

Overview

A design pattern is a way of solving a problem that

occurs repeatedly in a single program, or
commonly in many programs
Patterns allow us to decouple program elements,
giving us specific conceptual advantages
The patterns we will discuss now include
COMMAND, ITERATOR, FACTORY METHOD,
OBSERVER
Model View Controller architecture is a way of
separating functionality in GUI programs that uses
the OBSERVER pattern

Why?

Why study design patterns?

We've all worked with poorly designed code bases

The appropriate question is "why study software

architecture?"
Small changes cause a cascade of bugs in other parts
of the software
Large changes are difficult or impossible because the
code base is too complex and poorly structured for one
programmer to grasp

What about well designed code bases?

Small changes are easy and quick

Large changes are made easier because the
architecture is decoupled and well documented
See excerpt from GPP

Scenario

Your boss asks you to fix a bug

Your software uses a linked list to store data

But the program bugs out whenever it has to access the
data at two points at the same time, which is required
for a new feature being built by someone else
Your task is to allow two or more simultaneous access
points into the linked list
How do you do it?

What is a Design Pattern?

A Pattern Language: Towns, Buildings, Construction

In 1977, architect Christoph Alexander (and others)
published a book called A Pattern Language:
Towns, Buildings, Construction

This book described strategies for solving common

architectural problems

It described a step-by-step process to design and

construct buildings according to the needs of its users
AND it described common problems in all building
projects, with ways for solving them

These are called design patterns

It described 253 patterns, which together form a pattern

language a language of strategies for solving design
problems

Design Patterns
Design patterns in any domain have two basic
parts

1. The problem (or context)

2. The solution

The problem and solution are stated generally, to

apply to all varieties of a reocurring situation

Christoph 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."

Pattern 23: Parallel Roads

Alexander's patterns dealt with problems of

designing communities or campuses
Problem: Grid layout of roads leads to traffic
congestion and gridlock
Solution: Use long, parallel one-way roads

Keep parallel roads around 100 yards apart to allow use

of the intervening space

Pattern 127: Intimacy Gradient

Alexander's patterns also dealt with designing

homes
Problem: Some rooms are more private than others

Guests should not be admitted to bedrooms, for

example

Solution: Lay out spaces so that they create a

sequence which begins with the entrace and most
public parts of a building, then proceeds to the
slightly more private areas, and ends with the most
private domain

Pattern 132: Short Passages

Problem: Long hallways are sterile, intimidating,

and not very useful
Solution: Keep hallways short, and make them as
much like a room as possible

Include windows on one side

Carpet

Nooks

Book shelves

Unique shapes

Design Patterns in Software

Design patterns were quickly adopted for software

design, and famously recommended by the gang of
four book on software design patterns

Design Patterns: Elements of Reusable Design

As in architecture, a design pattern is a common

problem and a list of suggestions for addressing
that problem
It is usually a problem that occurs repeatedly

So the same, or a similar solution, can be used in every

case
The framework for solving one problem can be applied
in many areas of the software

This makes the software easier to understand, modify, and

maintain

The COMMAND Pattern

City-Building Game

You are designing a game where players can

design, construct, and manage their own city
Users can pick from a selection of structures,
including buildings, roads, and parks, then place
them on a grid

City-Building Game

Your game is aimed at consoles, so you build an

interface for controllers

Button A = pick a structure

Button B = place a structure

You add event handlers to buttons A and B, then move

on to the next task

A few months down the line, your company decides

that the game will also be released on PCs and
mobile devices

Now your event handlers are obsolete

How do you change your code to work for all types of
devices?

The COMMAND Pattern

Problem / Context

Solution

You want to reconfigure the function of buttons based

on the device and the user's preferences
Turn each user interaction into an object
Objects can then be associated with particular keys,
buttons, or GUI elements based on user settings

The COMMAND pattern essentially says that user

interactions can be managed and interpreted more
easily if we wrap them in objects

Turn method calls into objects / callbacks

Applying the COMMAND Pattern

In our city building game, we can create a

Command class, and two separate subclasses

Command

execute method - defines what this action actually does

PickStructure subclass

PlaceStructure subclass

Stores the selected structure

Stores the selected structure, and the location

Then, our input handler can store an array of type

Command

Command[] inputActions;

inputActions[0] = PickStructure

When A is pressed, call inputActions[0].execute

Undo

Using the COMMAND pattern also introduces a

second benefit: actions can be stored
We can add an undo method to our Command
superclass

Command

execute
undo

Then Commands can be stored in a stack, and if

the user wants to UNDO a building placement, all
we have to do is pop the top element from the
stack, and call undo

Undo

Undo will only work because command objects

have a state

They store both an action (method) and the way to do

that action (arguments)
Commands can be reversed because the undo method
knows how to do the opposite of what it did before,
using the stored state

It doesn't just remove any building, it removes the one at the

location where you placed one

COMMAND Pattern in Java

AbstractAction

In Java, the COMMAND pattern can be realized

using the AbstractAction superclass

AbstractAction is an abstract class that implements the

Action interface
The Action interface is a sub-interface of ActionListener

We can extend AbstractAction for each action the user

can perform

it has the actionPerformed method plus some constants and

methods for handling state

Objects of type AbstractAction can then be assigned to GUI

elements, such as buttons or menu items

Note the change in terminology

Command = AbstractAction

execute = actionPerformed

ConsoleAction and GuiAction

These two classes define two ways of showing

output to the user

Note the use of getValue(String) and putValue(String)

class GuiAction extends AbstractAction

{
...
}
class ConsoleAction extends AbstractAction
{
public ConsoleAction(String text, String desc)
{
super(text); // set the NAME value
putValue(SHORT_DESCRIPTION, desc);
}
public void actionPerformed(ActionEvent e)
{
System.out.println(getValue(NAME) + " " + getValue(SHORT_DESCRIPTION));
}
}

Attaching Actions

Attaching actions is as easy as calling setAction on

the JComponent that should execute that action

JButton btn1 = new JButton();

btn1.setAction(new GuiAction("GuiAction", "This is a GuiAction!"));
pnlTop.add(btn1);
JButton btn2 = new JButton();
btn2.setAction(new ConsoleAction("ConsoleAction", "This is a ConsoleAction!"));
pnlTop.add(btn2);

Menus

Actions can also be attached to menus at the top of

the window (File, Edit ... etc)

To create a menu, use JMenuBar, JMenu, and

JMenuItem

Set an action by calling setAction on a menu item

// create a new menu
JMenuBar myMenu = new JMenuBar();
JMenu mnuClickMe1 = new JMenu("Click Me!");
myMenu.add(mnuClickMe1);
JMenuItem mnuCat = new JMenuItem("Cat");
mnuCat.setAction(new GuiAction("GuiAction",
"This is a GuiAction!", new ImageIcon("nyan.png")));
mnuClickMe1.add(mnuCat);
myWindow.setJMenuBar(myMenu);

The ITERATOR Pattern

Traversing a Collection

Say we have a linked list class

How do we grant a class user access to the elements?

We could make a public Current pointer that points to a Node,

and let the user manipulate it as they like

We could make a method called next() that manipulates a

private pointer

But doesn't this violate encapsulation? Demeter's Law?

But this still allows the user to manipulate the internal state
And what if the user wants to look at two elements at once?

Why does the user have to know about a collection

at all?

A class user shouldn't have to know which data

structure you are using, just that it is a collection

The ITERATOR Pattern

Problem / Context

A class needs access to the elements stored in an

aggregate / collection

The aggregate / collection should not expose its internal

structure
There may be multiple clients that need simultaneous access

Solution

Define an iterator class that fetches one element at a

time
Each iterator keeps track of its own position with its own
internal state
Use a common interface that is broad enough to be
used by other aggregates

The ITERATOR Pattern

Client = the calling program

Iterator interface defines methods for accessing
and traversing elements

Concrete Iterator implements the Iterator interface and

stores the current position of the iterator

ITERATOR in Java

The Iterator interface defines the ITERATOR

pattern in Java

Defines three methods

hasNext, next, and remove

Typically implemented as an inner class on a

collection

A method returns an Iterator implementation

public LinkedListIterator getLinkedListIterator()

public MyIterator getMyIterator()

Breaking Encapsulation

Using the ITERATOR pattern like this still breaks

encapsulation

The class user must know which type of iterator your

class returns
AND he must know which method to call to get an
iterator from your class

Is there a design pattern to address this?

The FACTORY METHOD Pattern

Problem / Context

A program uses many types of classes that do X, and

must get objects to do X in the same way each time

Solution

A program uses many aggregator classes, and must get

iterators from each one

Define an interface with a single method that returns an

iterator
All classes will use the same method to return an
implementation of the same interface

The FACTORY METHOD pattern means that a

calling class need not know anything about classes
that do an activity

All it knows is they have one method with a specific

name that performs that task

The FACTORY METHOD Pattern

Aggregate interface defines methods for creating

an Iterator

Concrete Aggregate implements the Aggregate

interface and returns an instance of the Concrete
Iterator

FACTORY METHOD in Java

The FACTORY METHOD pattern is used in a lot of

different places in Java
The Iterable interface is one example

It has a single method

Iterator<T> iterator()

For all of the JCF collections, and any collection that

implements Iterable, a class user doesn't need to know
anything about the underlying implementation

returns an iterator over a set of elements of type T

or even the iterator inner class

Iterable is the interface that enables the enhanced for

loop

Example
public class LinkedList implements Iterable
{
public Node First;
public Node Last;
...
@Override
public java.util.Iterator iterator()
{
return new LinkedListIterator();
}
class LinkedListIterator implements Iterator<Object>
{
...
@Override
public boolean hasNext()
{
...
}
@Override
public Object next()
{
...
}
@Override
public void remove()
{
...
}
}
}

The OBSERVER Pattern

Event Driven Architecture

Programs used to be one long list of statements

Event driven architecture is a way of triggering

code based on actions by the user or some other
entity

The code isn't processed in a preset order, but in

whatever order is dictated by events

All modern GUIs rely on events

The first statement is executed, then the next, and the

next. Maybe there is a method call, which executes in
order. And eventually, the program ends because it runs
out of code.

In Java, when a JButton is clicked, it triggers the code

for the appropriate event listeners

This means that one bit of code must be capable of

watching for events in another bit of code

The OBSERVER Pattern

Problem / Context

A source object (A) is the source of events

An observer object (B) should respond to the events

Solution

Define an observer interface type

The source object (A) maintains a collection of objects
that implement the observer interface

and a way to add new observers

Whenever an event occurs, the source object (A)

notifies all observer objects (B)

The OBSERVER Pattern UML

Subject

Stores a list of its observers

provides a method for attaching observers

Observer interface defines a method that is called

when something occurs

Concrete Observer implements the Observer interface

The OBSERVER Pattern UML

In Java, Observer = Listener

Subject is a button, or anything that can detect events

Observer interface is a listener, like ActionListener

attach = addActionListener
notify = actionPerformed

Concrete Observer is the class that implements the

listener

The OBSERVER Pattern

in a Cellular Automaton

Cellular Automata

We previously discussed cellular automata in the

lecture on class design
A cellular automaton is a way to model a discrete,
dynamic system

https://www.youtube.com/watch?v=7j1RGylsA40
We focused on elementary cellular automata

A grid of values that changes over time

A single row of cells that can be on or off based on the

rules in the rule set
https://www.youtube.com/watch?v=SBJ7VqIX9zc

We designed a CA class to compute an elementary

cellular automaton using a rule set implemented as
an interface

Displaying an Elementary CA

A class for a CA is not particularly useful on its own

Part of the fun of a cellular automaton is watching the

patterns evolve in real time

How can we build a custom JComponent that will

display an elementary CA without coupling it to one
particular CA implementation or rule set?

We can use the OBSERVER pattern

The CA will hold a list of observers, which will listen for
events
The CA will throw events whenever it is updated
If anything is listening, then it can update itself
accordingly

Displaying an Elementary CA

OBSERVER pattern

CA aggregates observers
Whenever the CA changes, it notifies its observers,
which can update appropriately

Observers may be GUI components or music generators ...

Modifying the CA Class

We will use the ActionListener interface

CA will now store an ArrayList of ActionListeners

It will add an addActionListener method

And whenever the Update method is called, each

listener will be informed of the change

public class CA
{
private ArrayList<ActionListener> ActionListeners;
...
public void addActionListener(ActionListener NewActionListener)
{
if( NewActionListener != null ) ActionListeners.add(NewActionListener);
}
...
public void Update()
{
Cells = Ruleset.Calculate(Cells);

// tell all the listeners that an action occurred

if( ActionListeners != null && ActionListeners.size() > 0 )
{
ActionEvent UpdateEvent = new ActionEvent(this, 1, "Cells updated");
for( ActionListener a : ActionListeners ) a.actionPerformed(UpdateEvent);
}
}
}

Building the View

Then we just need to build a JComponent subclass

that implements ActionListener by drawing the CA
on screen
Override the actionPerformed method to respond to
the CA

Get the information from the event source

e.getSource

Call repaint() to trigger the paintComponent method

/**
* Respond to events from the automaton.
*/
@Override
public void actionPerformed(ActionEvent e)
{
Cells = ((CA)e.getSource()).GetCells();
MaxValue = ((CA)e.getSource()).GetMaximum();
repaint();
}

Building the View

Override the paintComponent method from the

JComponent class to draw the CA on screen
@Override
protected void paintComponent(Graphics g)
{
if (isOpaque())
{
//paint background
g.setColor(getBackground());
g.fillRect(0, 0, getWidth(), getHeight());
}
if (Cells != null)
{
Graphics2D g2d = (Graphics2D)g.create();
// Paint the cells. 0 = white, 1 = black
int CellHeight = this.getHeight() - 1;
double CellWidth = this.getWidth() / Cells.length;
int ColorIncrement = 255 / MaxValue;
for( int i = 0; i < Cells.length; i++ )
{
int NewColor = Cells[i] * ColorIncrement;
g2d.setColor(new Color(NewColor, NewColor, NewColor));
g2d.fillRect((int)(i * CellWidth), 0, (int)CellWidth, CellHeight);
}
g2d.dispose(); //clean up
}
}

Putting it Together

To use the class, instantiate a Ruleset, then a CA,

then a CellView, and add the CellView as a listener
to the CA
// instantiate the rule set
MyRuleset Rules = new MyRuleset();
CA Automaton = new CA(Size, Rules);
// instantiate the view
CA_View CellView = new CA_View();
// tell the CA_View to listen to the CA
Automaton.addActionListener(CellView);
// add the CA_View to the window
myWindow.getContentPane().add(CellView);
// tell the CA to start running
Automaton.Start();

Model View Controller

What is MVC?

MVC is a software architecture designed to

separate the front end from the back end

The front end is the GUI

The back end is the data handling code

Ultimately, the point of MVC is to decouple the front end

from the back end

Two objects are decoupled when they don't rely on each other
So the front end shouldn't rely on one particular back end
implementation
And the back end should rely on one particular GUI

How can we decouple two objects in Java?

Polymorphism

The front end only needs to know that the back end supports saving,
and the back end only needs to know that the front end supports
displaying

Model

the class that holds the actual data

View

the objects that are seen by the user

Typically the view is the GUI

Controller

accepts input

sends commands or information to the model

Three Parts of MVC

The controller can take multiple forms or even be

subsumed within the view
Typically, the controller is the event handlers that handle
events from the user and pass data to the model

Data flows from Controller > Model > View

Typical MVC Implementation

Data flows from the user, through the controller, to

the model, then finally to the view

Design Patterns in MVC

Either OBSERVER or COMMAND pattern can be

used to implement MVC architecture

If OBSERVER, then the model listens for events from

the controller, and the view listens for events from the
model
If COMMAND, then the controller sends commands to
the model and the view
The point is that the Model, View, and Controller
classes are decoupled by a command or observer
interface

So no class directly references the others

MVC Sequence Diagram

Controllers update model

Model tells views that data has changed
Views redraw

Course editor

MVC Example

Drawbacks

PATTERNS EVERYWHERE!

It's easy to start thinking that every aspect of a

program should be derived from a design pattern
After all, if patterns make some aspects of a
program so much more clear, shouldn't they be
applied everywhere

Can't every programming style be turned into a pattern?

Patterns may introduce two negative aspects into

your code base

1. Increased complexity (code bloat)

2. Increased overhead and run time

Increased Complexity

There are disadvantages to design patterns

Every pattern is a trade-off to a degree

See excerpt from Game Programming Patterns

Whenever you add a layer of abstraction or a place

where extensibility is supported, youre speculating that
you will need that flexibility later. Youre adding code
and complexity to your game that takes time to develop,
debug, and maintain.
When people get overzealous about this, you get a
codebase whose architecture has spiraled out of
control. Youve got interfaces and abstractions
everywhere. Plug-in systems, abstract base classes,
virtual methods galore, and all sorts of extension points.
the layers of abstraction themselves end up filling up
your mental scratch disk.

Increased Run Time

Patterns are used to decouple an algorithm from a

specific implementation
Whenever you do this, you introduce additional
classes and interfaces that may not be necessary
for a non-patterned implementation
There is a small hit to performance when you do
this

VERY SMALL

Still, if performance is critical, as in video games,

then you need to weigh the introduction of a pattern
carefully against the other demands on your
software

Anti-Patterns

Anti-Patterns

Patterns are typically used to lead a developer

toward a flexible solution
ANTI-patterns are used to lead a developer AWAY
from a bad solution
Anti-patterns are solutions that are commonly used,
but may be ineffective or counterproductive
Anti-patterns can be used to guide software
development, management, and business
decisions
Many examples of anti-patterns are compiled on
wikipedia

http://en.wikipedia.org/wiki/Anti-pattern

Blob

A system class that encapsulates unrelated

responsibilities

God Object

Anti-Pattern Examples

A system class that encapsulates too many

responsibilities

Poltergeist

A short-lived class with no significant responsibilities

Data formatting classes sometimes

Magic-Numbers

Using unexplained numbers in a method

See GUI and printing code

Anti-Pattern Examples

Object Orgy

Error Hiding

Public properties and methods expose internal state of

objects to other objects
Using exception-handling to hide bugs from developers
or users

Sequential Coupling

A class that requires its public methods to be called in a

specific order

Scenario

Scenario

Your boss asks you to fix a bug

Your software uses a linked list to store data

But the program bugs out whenever it has to access the
data at two points at the same time, which is required
for a new feature being built by someone else
Your task is to allow two or more simultaneous access
points into the linked list
How do you do it?

Use the ITERATOR and FACTORY METHOD

patterns

Write a method to return an iterator that maintains its

own internal state
Each calling class can use the method to get as many
iterators as they choose

Questions?

More

Links

A Pattern Language: Towns, Buildings,

Construction

The Oregon Experiment

http://gameprogrammingpatterns.com/

Anti-Patterns

http://www.jacana.plus.com/pattern/P0.htm

Game Programming Patterns

http://en.wikipedia.org/wiki/Oregon_Experiment

Pattern Language Online

http://en.wikipedia.org/wiki/A_Pattern_Language

http://en.wikipedia.org/wiki/Anti-pattern

r/cellular_automata

Links

http://www.reddit.com/r/cellular_automata/