IT Uppsala University User Interface Design II, … · IT Uppsala University User Interface Design 2 Design Patterns User Interface Design II, 1MD222 UU/IT @ 2006 2006-03-29 | #2

1

IT Uppsala University

User Interface Design 2 Design Patterns

User Interface Design II, 1MD222

2006-03-29 | #2UU/IT @ 2006

Design Patterns (DP)It’s not a course about DP (just a little)A lot of good design and efficient implementation is based on DP

In order to make sense, DPs require experience• They can be hard to understand at first• They can be hard to master, knowing when to

use, how to use etc.


2006-03-29 | #3UU/IT @ 2006

In the beginning…Francesco di Giorgio (1439-1501)• Master builders in

collected drawings of successful buildings

• The drawings were not precise drawings, but contained examples of good solutions and how they worked

2


2006-03-29 | #4UU/IT @ 2006

The Flower Power yearsChristopher AlexanderMathematician that became an architect• Notes on the Synthesis

of Form, 1964• A Pattern Language,

1977• The Timeless Way of

Building, 1979


2006-03-29 | #5UU/IT @ 2006

Why are there bad buildings?In ’Notes’ Alexander discusses how bad some buildings are:• ”Buildings are not characterized by adaptability,

quality or usability. Instead they are based on existing unspoken ’rules’. Over time the buildings are adapted for use, and some of the rules are modified for the better –without any explicit reason.”


2006-03-29 | #6UU/IT @ 2006

Alexandrian patternsAlexander’s view is that the buildings are bad because the people that are going to live there are not involved in the design process. He says that what matters is what happens in the building. This is nothing a designer can control. There has to be user involvement.

3


2006-03-29 | #7UU/IT @ 2006

Alexander’s conclusionsIn order to enable user participation, we all need to speak the same ”language”. This language is Design Patterns. Patterns are tools.


2006-03-29 | #8UU/IT @ 2006

DP a background in SmalltalkWard Cunningham & Kent Beck had in 1987 problem to complete a project and let a couple of users finish the design• The result was 5 Smalltalk DP


2006-03-29 | #9UU/IT @ 2006

First DP ever!#1: WindowPerTask• Make a specific window for each task the user

must perform. All of the information needed to complete a task should be available in the FewPanes of the window. Assume prerequisite tasks have been completed (if they haven't, the user will simply change windows.)

The first DPs were about User Interfaces!

4


2006-03-29 | #10UU/IT @ 2006

Gang of four (GoF)OOPSLA workshop 1991:• Coincidentally, Erich

Gamma, Richard Helm, Ralph Johnson, and John Vlissides were all there; they would later become the Gang of Four' that authored the Design Patterns book.


2006-03-29 | #11UU/IT @ 2006

DefinitionA solution of a defined problem in a certain context• Context is a set of recurring situations• Problems are goals and limits in this context• A solution describes the steps needed for reaching your

goal


2006-03-29 | #12UU/IT @ 2006

Not everything is a DPProblem• How do I get back my winning lottery ticket before

it’s too late?Context• The dog ate my ticket.

Solution• Dissect the dog.

5


2006-03-29 | #13UU/IT @ 2006

Why use DP?Reuse design. More powerful than to reuse code.A common language. High level meaning. • We can actually use DPs as words• We do that by refering to things as ”cache” or

”proxy” – these are DPs.Increased understanding of solutions.


2006-03-29 | #14UU/IT @ 2006

Iterator


2006-03-29 | #15UU/IT @ 2006

IteratorGoal: to be able to traverse all objects in a set without knowing about how they are stored.

6


2006-03-29 | #16UU/IT @ 2006


2006-03-29 | #17UU/IT @ 2006

Iterator in Javapublic interface Iterator

boolean hasNext();object next();

void remove(); }


2006-03-29 | #18UU/IT @ 2006

Iterator in JavaHashSet hash = new HashSet();hash.add(”Hi”); hash.add(”Ho”);LinkedList list = new LinkedList();list.add(”Hi”); list.add(”Ho”);

void print(Iterator it) {while (it.hasNext()) {

System.our.println(it.next());}

}

print(hash.iterator());print(list.iterator());

7


2006-03-29 | #19UU/IT @ 2006

Singleton”a card that is the only one of its suit”


2006-03-29 | #20UU/IT @ 2006

SingeltonThere can be only one instance of a certain class:• One database, one catalogue, one backup, one

rot object, etc.As developers, we need to make sure this property holds true – by design.


2006-03-29 | #21UU/IT @ 2006

final class Singleton {private static Singleton s = new Singleton(47);private int i;private Singleton(int x) { i = x; }public static Singleton getReference() { return s;

}public int getValue() { return i; }public void setValue(int x) { i = x; }

}

8


2006-03-29 | #22UU/IT @ 2006

Factory


2006-03-29 | #23UU/IT @ 2006

FactoryWe need to be able to extend the number of objects, without knowing exactly with what/how many.It is not enough to use ”interface”, because we then spread this knowledge to many places in the code. Solution: to use a ”factory” that will create objects for us.• Should we need to add new objects, it is enough

to change the factory.


2006-03-29 | #24UU/IT @ 2006

9


2006-03-29 | #25UU/IT @ 2006


2006-03-29 | #26UU/IT @ 2006

Factory, solutionabstract class Shape {public abstract void draw();public abstract void erase();public static Shape factory(String type) {if(type.equals("Circle")) return new Circle();if(type.equals("Square")) return new Square();throw new RuntimeException("Bad shape creation: " + type);

}}

class Circle extends Shape {Circle() {} // Friendly constructorpublic void draw() { System.out.println("Circle.draw");

}public void erase() { System.out.println("Circle.erase");

}}// Shape shape = Shape.factory(”Circle”);Shape.draw();


2006-03-29 | #27UU/IT @ 2006

Factory, common useinterface Crypto {

// encode, decode, keys, etc…}

Message msg = new Message(”top secret string”);Crypto topSecret =

OurSecureFactory.getCrypto(”RSA”);Crypto notSoSecret = OurSecureFactory.getCrypto(”Caesar”);

Crypto std = OurSecureFactory.getCrypto();

send(topSecret.encode(msg));send(notSoSecret.encode(msg));send(std.encode(msg));

10


2006-03-29 | #28UU/IT @ 2006

Command


2006-03-29 | #29UU/IT @ 2006

CommandPurpose• Wrap commands in an object. Then we can pass

commands around, to other objects.Why• We can stack commands until later, we can run

them in a certain order, etc. • Easy to implement ”undo”.


2006-03-29 | #30UU/IT @ 2006

Command

11


2006-03-29 | #31UU/IT @ 2006

Commandinterface Command {

void execute();}

class Hello implements Command {public void execute() {

System.out.print("Hello ");}

}


2006-03-29 | #32UU/IT @ 2006

Commandvoid runAllCommands(Collection col) {Iterator it = col.iterator();while (it.hasNext()) {Object o = it.next();if (o instanceof Command) {((Command)o).execute();

}}

}


2006-03-29 | #33UU/IT @ 2006

Command, common useJButton bold = new JButton(”Quit”);// commandActionListener boldCmd = new ActionListener() {

public void actionPerformed(ActionEvent e) {setBold();// save what we did so we may undo

undo.put(this);}

};bold.addActionListener(boldCmd);

12


2006-03-29 | #34UU/IT @ 2006

Observer


2006-03-29 | #35UU/IT @ 2006

PurposeDefine a one-to-many relationship, so that when an object changes state, all dependent objects are automatically notified.


2006-03-29 | #36UU/IT @ 2006

WhyOur code consists of many independent parts. We want to keep them independent. Information that is shared should be consistent.Common use is in user interfaces; if a value changes, then the presentation of that value needs to be updated.

13


2006-03-29 | #37UU/IT @ 2006

Observer


2006-03-29 | #38UU/IT @ 2006

Collaborations


2006-03-29 | #39UU/IT @ 2006

Motivation

14


2006-03-29 | #40UU/IT @ 2006

ApplicabilityWhen an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently. When a change to one object requires changing others, and you don't know how many objects need to be changed.When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled.


2006-03-29 | #41UU/IT @ 2006

Delegation


2006-03-29 | #42UU/IT @ 2006

DelegationInheritance is a static relation. Sometimes we need a more dynamic solution.

15


2006-03-29 | #43UU/IT @ 2006

Inheritance a solution?


2006-03-29 | #44UU/IT @ 2006

Delegation instead?


2006-03-29 | #45UU/IT @ 2006

Delegationclass Instrument {

public void play() { System.out.println(”Instrument play”);}

class Guitar extends Instrument {public void play() { System.out.println(”Guitar play”);

}--------interface Instrument {

public void play();}

class Guitar inplements Instrument {public void play() { System.out.println(”Guitar play”);

}// clearinstrumentShop.add(new Instrument() { public void play() { //

oink..

16


2006-03-29 | #46UU/IT @ 2006

Decorator


2006-03-29 | #47UU/IT @ 2006

Decorator

Component

operation()

Decoratable

operation()

Decorator2

operation()addedBehavior()

Decorator1

addedState

operation()


2006-03-29 | #48UU/IT @ 2006

Decorator, problem

CafeLatte CafeLatteDecaf CafeLatteDecafWhipped

CafeLatteExtraEspresso CafeLatteExtraEspressoWhipped

CafeLatteWet

CafeLatteWetWhipped

CafeLatteWhipped

CafeMocha CafeMochaDecaf CafeMochaDecafWhipped

CafeMochaExtraEspresso CafeMochaExtraEspressoWhipped

CafeMochaWet

CafeMochaWetWhipped

CafeMochaWhipped

Cappuccino CappuccinoDecaf CappuccinoDecafWhipped CappuccinoDry

CappuccinoExtraEspresso CappuccinoExtraEspressoWhipped CappuccinoDryWhipped

CappuccinoWhipped

CoffeeShop

Espresso DoubleEspresso

17


2006-03-29 | #49UU/IT @ 2006

Decorator, solutionA Decorator adds responsibility to a component by wrapping it, but the Decorator conforms to the interface of the component it encloses, so the wrapping is transparent.

Chocolate

CoffeeShop

Decaf

Decorator

Espresso FoamedMilk

Mug

SteamedMilk Whipped

«interface»DrinkComponent


2006-03-29 | #50UU/IT @ 2006

Decorator, solutioninterface DrinkComponent {String getDescription();float getTotalCost();

}

abstract class Decorator implements DrinkComponent

{protected DrinkComponent component;Decorator(DrinkComponent component) {this.component = component;

}public float getTotalCost() {return component.getTotalCost();

}public abstract String getDescription();

}

class Espresso extends Decorator {private float cost = 0.75f;private String description = " espresso";

public Espresso(DrinkComponentcomponent) {super(component);

}public float getTotalCost() {return component.getTotalCost() + cost;

}public String getDescription() {return component.getDescription() +

description;}

}


2006-03-29 | #51UU/IT @ 2006

Decorators in Java/Swingpublic interface Border

Insets getBorderInsets(Component c)boolean isBorderOpaque()void paintBorder(Component c, Graphics g, int

x, int y, int width, int height) }

Documents

IT Uppsala University User Interface Design II, … · IT Uppsala University User Interface Design 2 Design Patterns User Interface Design II, 1MD222 UU/IT @ 2006 2006-03-29 | #2