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?

● The appropriate question is "why study software architecture?"

● We've all worked with poorly designed code bases● 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

● You want to reconfigure the function of buttons based on the device and the user's preferences

● Solution● 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

● Stores the selected structure

– PlaceStructure subclass● 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

– it has the actionPerformed method plus some constants and methods for handling state

● We can extend AbstractAction for each action the user can perform– 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 menuJMenuBar 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● But doesn't this violate encapsulation? Demeter's Law?

– We could make a method called next() that manipulates a private pointer

● 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 aggregator classes, and must get iterators from each one

● A program uses many types of classes that do X, and must get objects to do X in the same way each time

● Solution● 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()

● returns an iterator over a set of elements of type T

● 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– or even the iterator inner class

● Iterable is the interface that enables the enhanced for loop

Examplepublic class LinkedList implements Iterable{

public Node First;public Node Last;...

@Overridepublic java.util.Iterator iterator(){

return new LinkedListIterator();}class LinkedListIterator implements Iterator<Object>{

...@Overridepublic boolean hasNext(){

...}@Overridepublic Object next(){

...}@Overridepublic void remove(){

...}

}}

The OBSERVER Pattern

Event Driven Architecture● Programs used to be one long list of statements

● 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.

● 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● 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– attach = addActionListener

● Observer interface is a listener, like ActionListener– notify = actionPerformed

● Concrete Observer is the class that implements the listener

The OBSERVER Patternin 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● A grid of values that changes over time

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

● 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 changepublic 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 occurredif( 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. */@Overridepublic 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@Overrideprotected 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 = blackint 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 setMyRuleset Rules = new MyRuleset();

CA Automaton = new CA(Size, Rules);

// instantiate the viewCA_View CellView = new CA_View();// tell the CA_View to listen to the CAAutomaton.addActionListener(CellView);

// add the CA_View to the windowmyWindow.getContentPane().add(CellView);

// tell the CA to start runningAutomaton.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

Three Parts of MVC● 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● 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

MVC Example● Course editor

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, you’re speculating that you will need that flexibility later. You’re 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. You’ve 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

Anti-Pattern Examples● Blob

● A system class that encapsulates unrelated responsibilities

● God Object● 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

● Public properties and methods expose internal state of objects to other objects

● Error Hiding● 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● http://en.wikipedia.org/wiki/A_Pattern_Language

● The Oregon Experiment● http://en.wikipedia.org/wiki/Oregon_Experiment

● Pattern Language Online● http://www.jacana.plus.com/pattern/P0.htm

● Game Programming Patterns● http://gameprogrammingpatterns.com/

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

●

Links● r/cellular_automata

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

●