Beteendemässiga designmönster

Beteendemässiga
designmönster
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor

Problem – olika kontroller av
förfrågningar
● Beroende på ett anrops parametrar, vill vi göra
olika slags kontroller
– T.ex. Webbservern anropas enligt autenticering,
efter vilken sida som frågats, osv.
● Klumpigt att ha alla kontrolleringar på ett och
samma ställe – de har inget med varann att
göra
● Om vi har dem på flera ställen, ska klienten inte
behöva veta om dom alla

Chain of Responsibility

I praktiken

Chain of Responsibility
● Anropet skickas iväg till olika hanterare i given
ordning.
● Vi har tre alternativ:
– Den första som sköter anropet ger svar
– Vi kan skicka förfrågan vidare till nästa
hanterare
– Eller så hindrar vi förfrågan från att gå vidare
● “Hindrandet” brukar också skötas så att vi ger
ett visst svar, t.ex. ett felmeddelande

class Handler1 implements HandlerInterface {
void handleRequest(Request req, Response rsp, Chain chain) {
...
chain.nextRequest();
}
}
class Handler2 implements HandlerInterface {
void handleRequest(Request req, Response rsp, Chain chain) {
response.XXX; // Fill in the response
chain.giveResponse()
}
}
class Handler3 implements HandlerInterface {
void handleRequest(Request req, Response rsp, Chain chain) {
chain.stopResponse();
}
}

Chain of Responsiblity - diverse
● Frigör sändaren av meddelandet/anropet från
mottagaren
● Gör objektet enklare
● Möjliggör dynamisk ändring av kedjan
● Exekveringen är inte garanterad; tänk om ingen
i kedjan sköter om förfrågan
● Ev. svårt att inse i vilken ordning de olika
hanterarna ska vara
● Ev. svårt att debugga
– Nyttigt dock att kedjan syns från början till
nuvarande position i tracebacken...

Application
Chain of Responsibilityprocessen/objekten
Chain
nextHandler
nextHandler
Hanterare1 Hanterare2 Hanterare3

Problem - undo/redo
● Flera applikationer har nytta av undo/redomöjligheter
– T.ex. ett textbehandlingsprogram

Command

MoveShapeCommand
● Vi har en klass MoveShapeCommand som
– Kan flytta ett objekt från sin gamla plats till den
nya givna platsen
– Kan återställa detta (undo)
– Kan om-exekvera kommandot (redo)
● Konstruktorns uppgift (eller ev. skilda metoder)
är att etablera informationen som behövs för att
exekvera ovanstående

Första försöket
class MoveShapeCommand implements
Command {
Shape s;
}
int x;
int y;
public MoveShapeCommand(
Shape ss,
int xx,
int yy) {
s = ss;
x = xx;
y = yy;
}
void execute() {
int oldx = s.getX();
int oldy = s.getY();
s.setX(x);
s.setY(y);
x = oldx;
y = oldy;
}
}
void undo() {
int oldx = s.getX();
int oldy = s.getY();
s.setX(x);
s.setY(y);
x = oldx;
y = oldy;
}
void redo() {
int oldx = s.getX();
int oldy = s.getY();
s.setX(x);
s.setY(y);
x = oldx;
y = oldy;
}

class MoveShapeCommand implements Command {
Shape s;
int x;
int y;
public MoveShapeCommand(Shape ss, int xx, int yy) {
s = ss;
x = xx;
y = yy;
}
void undo() {
}
int oldx = s.getX();
int oldy = s.getY();
s.setX(x);
s.setY(y);
x = oldx;
y = oldy;
}
void redo() {
undo();
}
● Många kommandon kan
implementeras så att
execute() är samma som
redo()
● Många kommandon kan
implementeras så att redo()
är samma som undo()

● Man kan även
Command - diverse
– Exekvera kommandon senare
– Logga kommandon
– Serialisera kommandon
– Göra t.ex. Playback
● Nyttig även utan undo!
● Detalj: Undo/Redo kan ändå implementeras på
olika sätt, jämför t.ex. Word och Emacs

Command Queue med en Thread
Pool
● Många klienter vill få sina kommandon uträttade
● P.g.a. kapasitetsproblem vill man inte exekvera
kommandon genast när de kommer
● Kommandon lagras i kö
● En skild mängd med threads plockar ut
kommandon och exekverar dem
Client 1
Client 2
Work4
Work3
Work2
Work1
Thread 1
Thread 2

● Vi kan länka
flera
kommandon in
i ett nytt
kommando
● Observera att
redo() kör
kommandona
baklänges
Macro Command
class MacroCommand implements Command {
Command[ ] cmds;
public MacroCommand(Command[ ] c) {
cmds = c;
}
public addCommand(Command c) {
...
}
void undo() {
for (int i = cmds.size() - 1; i >= 0; --i) {
Command c = cmds[i];
c.undo();
}
}
void redo() {
for(Command c: cmds) {
c.redo();
}
}
}

Interpreter
● Vi behöver ett enkelt skriptspråk i vårt program
● Behövs:
– Språk (grammatik)
– Lexer
– Parser
– Interpreterare

● Språket brukar ges i Backus-Naur Form (BNF)
● Exempelvis ett språk för enkla beräkningar:
– E -> Terminal | Operation
– Operation -> Plus | Minus
– Plus -> E '+' E
– Minus -> E '-' E
– Terminal -> [0-9]+
● (Vi funderar inte här över operatorers
precedenser)

Syntaxträd
● Syntaxträdet för (1023 + x) - 500

● interpret()
Interpreter-mönstret

import java.util.*;
interface Expression {
public int interpret(HashMap variables);
}
class Number implements Expression {
private int number;
public Number(int number) { this.number = number; }
public int interpret(HashMap variables) { return number; }
}
class Plus implements Expression {
Expression leftOperand;
Expression rightOperand;
public Plus(Expression left, Expression right) {
leftOperand = left;
rightOperand = right;
}
}
public int interpret(HashMap variables) {
return leftOperand.interpret(variables) + rightOperand.interpret(variables);
}
class Minus implements Expression {
Expression leftOperand;
Expression rightOperand;
public Minus(Expression left, Expression right) {
leftOperand = left;
rightOperand = right;
}
}
public int interpret(HashMap variables) {
return leftOperand.interpret(variables) - rightOperand.interpret(variables);
}
class Variable implements Expression {
private String name;
public Variable(String name) { this.name = name; }
public int interpret(HashMap variables) {
return variables.get(name);
}
}
Exempel

Evaluering
public class InterpreterExample {
public static void main(String[] args) {
String expression = "(1023 + x) - 500";
Evaluator sentence = new Evaluator(expression);
HashMap variables = new HashMap();
variables.put("x", 1);
int result = sentence.evaluate(variables);
System.out.println(result);
}
}

Men!
● Det finns betydligt bättre verktyg för tillverkning
av parsers och interpreterare
– Yacc
– Lexx
– Bison
● Bäst att gå en kurs i kompilatorteknik

Gammalt problem: vi vill anropa en
metod i alla lövnoder
● Att iterera igenom trädstrukturen och anropa
alla lövnoders operation1() var jobbigt
● Måste vi copy-paste koden för att anropa
operation2() ?

En alternativ lösning
● Skild iteratorklass som bara returnerar lövnoder
– Lite jobbig att skriva, men behöver bara göras en
gång

● Användning:
● Eller (i Java 5):
void m(Component c) {
Iterator i = c.createLeafIterator();
while (i.hasNext()) {
Leaf lf = i.next();
lf.operation1();
}
}
void m(Component c) {
for (Leaf lf : c.createLeafIterator() ) {
lf.operation1();
}
}

Iterator
● Mönstret ger ett gränssnitt för att iterera igenom
valfria samlingar
● Vill någon klass delta, kan man bara göra en
lämplig subklass till Iterator

Iterator - diverse
● Iteratorn behöver inte gå igenom en
existerande samling
– En generator genererar samlingen on-the-fly från
t.ex. formler
– Kan kombinera samlingar, filtrera element från dem
o.s.v.
● Själva iteratorn och klassen som har samlingen
brukar vara lite i symbios
– Vad händer om samlingen modifieras medan någon
annan itererar igenom samlingen?
– ( Problemet är att klienten bestämmer hur snabbt
iteratorn används )

Och i ett bättre språk än Java...
● “Javafierad” syntax...
● Användning:
void m(Component c) {
c.callLeafs(lambda(Leaf x) {
x.operation1();
});
}
class Composite {
void callLeafs(Function f) {
for (Component c: children) {
c.callLeafs(f);
}
}
}
class Leaf {
void callLeafs(Function f) {
f(this);
}
}
Du behöver
inte kunna
denna
sida

Vem bestämmer?
● Flera samarbetande komponenter kan lätt bli
råddigt
– Kan vara n*(n-1)/2 parrelationer!
– Vem uppdaterar vem?
– Eventuella nya objekt ska lätt kunna integreras

Mediator
● Alla komponenter uppdaterar sig bara till ett
ställe, som sedan uppdaterar de övriga
● Lättare att skriva och förstå komponenterna

Eller mer generellt...

Mediator
● Ökar återanvändbarheten bland
komponenterna en aning
● Vi kan införa gemensamma regler för
kommunikation
– Minskar på olika kommunikationssätt => lättare att
förstå
● Mönstrets centrala objekt kan bli krångligt
● Jämför med Facade: fasaden är till för att
klienten ska få ett enkelt och bättre gränssnitt,
Mediator är till för att de interna komponenterna
ska kunna samarbeta lättare

Rollback till ett tidigare tillstånd
● Objekt kan behöva “snapshottas” för att kunna
spara deras tillstånd
● T.ex följande kan vara nyttiga att kunna
återställas till originaltillståndet
– Slumptalsgeneratorer
– Tillståndsmaskiner

Spara / ladda data
● De flesta applikationer vill spara och ladda data
– Spel, kontorsprogram, osv.
● Automatisk serialisering är en dålig idé – tycker
jag
– Ev. beroende på just den versionen av
programmeringsomgivningen
– Ev. svårt att vara kompatibel om dataformatet
ändrar (dvs fälten ändrar i klassen)
– Andra program, skriva i andra språk, kan ha svårt
för att kommunicera i samma format

Memento
● Märk att klienten inte har tillgång till datat
● Snapshotten över datat sparas i en skild klass!
● Kan vara tidskrävande att spara eller ladda
datat

Problem - ändringar i data leder till
fler ändringar
● När något data ändrar, behöver vi ofta
uppdatera något annat data också
– Exempel finns i överflöd: vilket system som helst
har nytta av att en ändring “triggar” en annan
ändring
● Problemet är att vi inte vet vad som behöver
uppdateras
class Player {
int health;
void damage(Weapon w, int points) {
health -= points;
// Tell the rest
GUI.tellOtherPlayersIGotHit();
GUI.tellMyScreenDrawingRoutineIGotHit();
GUI.tellMyScreenThatILostHealth();
...
// Did we forget anybody?
}
}

● Ett system består av
● Subjekt
● Observerare
Generellt
● Behöver inte vara skilda objekt, ett subjekt kan
även observera någon

Är du intresserad?
● Egentligen är subjektet inte intresserad av att
berätta om sin ändring åt de observerare den
känner till
– Beroendet är dubbelt; både subjekt och observerare
vet om varandra
– En ny observerare kräver en ändring i subjektet
● Subjektet borde berätta åt alla de observerare
som är intresserade av subjektet
– Men observerare bör berätta att de är intresserade

● Subject-klassen vet om sina observerare
● Men S1 och S2 behöver inte veta

Kodexempel
class Subject {
private ArrayList observers;
protected void notify() {
for (Observer o: observers) {
o.update(this);
}
}
public void attach(Observer o) {
observers.add(o);
}
public void detach(Observer o) {
observers.remove(o);
}
}
class S1 extends Subject {
public void doSomething() {
notify();
}
}
● Användning:
S1 s = new S1();
...
...
...
Observer o1 = new O1();
Observer o2 = new O2();
s.attach(o1);
s.attach(o2);
...
s.doSomething();

1
Kodexempel
class Subject {
private ArrayList observers;
protected void notify(...) {
for (Observer o: observers) {
o.update(this, ...);
}
}
2 3
}
public void attach(Observer o) {
observers.add(o);
}
public void detach(Observer o) {
observers.remove(o);
}
● 1) notify() kan bara
anropas av
subklasserna
● 2) observerarna får
veta vilket subjekt
som ändras
● 3) eventuella extra
parametrar kan ges

Varianter
● Inget data skickas med notify() versus data kan
skickas
– Kan eventuellt använda olika notify-metoder
● Observeraren får inte veta vilket subjekt som
ändrats versus en referens till subjektet skickas
med
– För varje observerare finns högst ett subjekt
● Ett subjekt kan ha flera s.k. signaler
– T.ex. QT-biblioteket
– Brukar kallas för signal/slot-mekanismen

● Andra namn:
– Model/View
– Publish/Subscribe
– Document/View
– Observer
Subject/Observer
● Kan ge prestandaproblem med många subjekt/
observerare
● Kan åka i oändlig loop om subjekt S anropar
observeraren, som själv är ett subjekt som
observeras av S...

C# delegate
Du behöver
inte kunna
denna
sida
● C# har subject-observer mönstret inbyggt i form
av delegater

Automater
● En del system fungerar
enligt klara regler
– Coca Cola-maskin,
datorprotokoll
– Regelantalet kan vara
stort & komplicerat
● Systemen fungerar
olika vid olika
tidpunkter!
● Modellering av dessa
görs bäst med
tillståndsmaskiner
(eng. state machines)

Tillståndsmaskiner
● De facto standard: UML 2.0 State machines
– Maskinerna kan även presenteras i t.ex. tabellform

Vad består en tillståndsmaskin av?
● Vakter (eng. guards)
● Händelser (eng. events)
● Tillstånd (eng. states)
● Aktioner (eng. actions)
● Eventuella tillägg
– enter/exit, hierarkier, synkronisering, fork/join,
historia

Ändringar i beteendet - dynamiskt!
● Hur ska vi få vårt system att fungera olika efter
olika metodanrop / olika tidpunkter?
● Dvs, hur ska vi få tillståndsmaskinen in i
systemet?

Implementationsidéer
● Switch-tabell inne i klassen
– Oöverskådligt när det blir för
stort
● Vad som helst inne i klassen
– Råddigt, oöverskådligt...
● Något annat?
class CokeMachine {
int state;
public void insertCoin() {
switch (state) {
case STATE1:
state = ...;
break;
case STATE2:
state = STATE3;
increaseSum();
break;
...
}
...
}

State
● De olika tillstånden representeras som
subklasser
– Måste finnas något sätt att signalera från tillstånden
att kontexten skall byta tillstånd

Implementation via olika subklasser
class CokeMachineState2 implements State {
public void insertCoin(Context myCokeMachine) {
myMachine.increaseSum();
myMachine.playSound();
myMachine.switchState(moneyInserted);
}
...
}
● Men det bästa är att ha ett verktyg som
genererar tillståndsmaskinen från grafiska
representationen

Problem - QuakeBot
● Vi vill ha datorspelare som spelar på olika sätt
– Roligare säljer bättre mer kul & fyrk

Strategy
● Vi enkapsulerar valet av strategi
● Olika datorspelar har gemensam
huvudfunktionalitet (ev. fungerar enligt
samma villkor/regler), men strategin
gör att de reagerar på olika sätt

Skillnader mellan State och Strategy
● Strategy är en samling algoritmer eller idéer för
att nå något mål
– Vi byter oftast inte strategi
● State är en algoritm i ett visst specifikt tillstånd
– Vi byter tillstånd enligt behov

Andra exempel
● Strategimönstret är inte bara för spel
● I mindre skala: en sorteringsrutin sorterar enligt
ett visst kriterium – sorteringsstrategin!
– Alla rutiner delar på gemensamma regler (= sortering
och dess slutresultat)
– Men de reagerar på olika sätt (= kriteriet)

Problem – bara små förändringar
när vi subklassar
● Ibland skapar man klasshierarkier där
subklasserna
– Ändrar de definierade metoderna väldigt lite
– Måste göra vissa saker i rätt ordning
class HamPizza {
void bakeThePizza() {
makeDough();
addTomatoSauce();
addSpices();
addIngredients();
addCheese();
insertIntoOven();
wait();
removeFromOven();
}
}
class SalamiPizza {
void bakeThePizza() {
makeDough();
addTomatoSauce();
addIngredients();
addSpices();
addCheese();
insertIntoOven();
wait();
removeFromOven();
}
}

class Pizza {
final public void bakeThePizza() {
makeDough();
addTomatoSauce();
addSpices();
addIngredients();
addCheese();
insertIntoOven();
wait();
removeFromOven();
}
abstract protected void makeDough();
}
Vårt templat
protected void addTomatoSauce() {
; // add some tomate sauce
}
Template Method
class HamPizza {
protected void makeDough() {
...
}
protected void addTomatoSauce() {
...
}
}
Defaultbeteendet
är
inte OK;
subklassen
måste definiera
metoden
Defaultbeteendet
kan
vara OK; inget
undantag

Template Method
● Vacker användning av Open-Closed-principen!
● Tvingar subklasserna att göra saker i en viss
ordning
● Håller kontrollen i superklassen
● Själv templatet innehåller de nödvändiga
delarna, och genom omdefinierbara
metodanrop fås variation från subklasserna

Skillnader mellan Template Method
och Strategy
● Template Method
– Håller kontrollen i superklassen
– Gemensam kod kan återanvändas i superklassen
● Strategy implementerar “något större”, behöver
mer datafält osv
– En strategi är en algoritm eller flera relaterade
algoritmer; strategierna är en familj av utbytbara
algoritmer
– Kontrollen inte viktig; strategierna får göra hur de
vill för att uppnå målet
– Kod brukar inte återanvändas mellan klasser

Problem – anrop av metod enligt
parameterns typ
● Vi har följande klasshierarki...

● ...och ett objektdiagram enligt det
● Analyseraren skall gå
igenom alla noder och
analysera dem enligt typ
● Dvs, vi vill ha mer
funktionalitet för varje
klass utanför
klassdefinitionerna

Första försöket
class Analyzer {
public void iteratePart(CarPart node) {
analyze(node);
for (CarPart c : node.getChildren()) {
iteratePart(c);
}
}
}
private void analyze(CarPart c) {
// Hmm, I wonder if it's a Seat, an Engine or something else?
if (c instanceof Engine) {
// Check Engine data
} else if (c instanceof Seat) {
// Check Seat data
} ...
}
● Problem: vi måste vara medvetna om alla
subklasser!

Vad vi behöver
class Analyzer {
public void visit(Engine e) {
// Check Engine data
}
public void visit(Seat s) {
// Check Seat data
}
...
}
● Om vi glömmer en subklass, eller om en ny
subklass skapas, kommer kompilatorn att
klaga, för det finns ingen “catch-all” i stil med
visit(CarPart c)

Lösning
abstract class CarPart {
public ArrayList parts = new ArrayList();
public void iterateParts(Analyzer a) {
accept(a);
for (CarPart c : this.getChildren()) {
c.iterateParts(a);
}
}
abstract protected void accept(Analyzer a);
}
class Engine extends CarPart {
protected void accept(Analyzer a) {
a.visit(this);
}
}
class Seat extends CarPart {
protected void accept(Analyzer a) {
a.visit(this);
}
}
...
class Analyzer {
public void visit(Engine e) {
// Check Engine data
}
public void visit(Seat s) {
// Check Seat data
}
...
}
● => Kompilatorn klagar om vi
glömmer en subklass från
Analyzer!

Lösning
abstract class CarPart {
public ArrayList parts = new ArrayList();
public void iterateParts(Analyzer a) {
accept(a);
for (CarPart c : this.getChildren()) {
c.iterateParts(a);
}
}
abstract protected void accept(Analyzer a);
}
class Engine extends CarPart {
2
1
protected void accept(Analyzer a) {
a.visit(this);
}
}
class Seat extends CarPart {
protected void accept(Analyzer a) {
a.visit(this);
}
}
...
class Analyzer {
public void visit(Engine e) {
// Check Engine data
}
public void visit(Seat s) {
// Check Seat data
}
...
}
3
● Märk att genomgång av
strukturen (1) är skild
från accept-metoderna
(2)
● Den nya funktionaliteten
ges i (3)

Eller ett enkelt alternativ...
class CarPart {
public ArrayList parts = new ArrayList();
abstract public void accept(Analyzer a);
}
class Engine extends CarPart {
public void accept(Analyzer a) {
a.visit(this);
}
}
class Seat extends CarPart {
public void accept(Analyzer a) {
a.visit(this);
}
}
...
class Analyzer {
public void iterateParts(CarPart node) {
node.accept(this);
for (CarPart c : node.getChildren()) {
iterateParts(c);
}
}
public void visit(Engine e) {
// Check Engine data
}
public void visit(Seat s) {
// Check Seat data
}
...
}

Visitor
● Vi har tilläggt ny
funktionalitet till
klasshierarkin utan att
funktionaliteten finns i
subklasserna
– Alla subklasser måste dock
ha en skild identisk metod
● Iterering genom strukturen
skild från acceptans =>
olika möjligheter till iteration

Problem – hur får vi double dispatch
till Java / C# / C++ ?
A a = new A();
P p = new P();
a.m(p);
A a = new B();
P p = new P();
a.m(p);
A a = new A();
P p = new U();
a.m(p);
● Vilken metod kommer egentligen att anropas?
– (Dvs,vilka omdefinitionsmöjligheter har vi?)
A a = new B();
P p = new U();
a.m(p);

Java / C# / C++ är single dispatch
● Single dispatch:
– a.m(p) anropas enligt den dynamiska typen av a
– a.m(p) anropas inte enligt den dynamiska typen av
parametern p – om p är ett P- eller U-objekt
påverkar inte
● Dvs, enbart A.m(P p) eller B.m(P p) kommer att
anropas
● Dvs, det är inte möjligt att anropa en skild rutin
om vi använder oss av ett U-objekt

Det intressanta i vårt exempel
● Vi kan göra subklasser till Analyzer
– Vi har alltså flera CarPart-objekt och något
Analyzer-objekt
● Därmed kommer visit-metoderna att anropas
– Enligt den dynamiska typen på CarPart-objektet
– Enligt den dynamiska typen på Analyzer-objektet
● Double dispatch

● En ny subklass till
CarPart kommer
att kräva en ny
visit-metod i
Analyzer
● En ny (abstrakt)
visit-metod
kommer att kräva
en omdefiniering i
varje subklass till
Analyzer
class Analyzer {
public void iterateParts(CarPart node) {
node.accept(this);
for (CarPart c : node.getChildren()) {
iterateParts(c);
}
}
abstract public void visit(Engine e);
abstract public void visit(Seat s);
...
};
class MyAnalyzer extends Analyzer {
public void visit(Engine e) {
...
}
public void visit(Seat s) {
...
}
};

Visitor
● Behövs inte så ofta, men när det behövs är det
nyttigt
– Tillägg av funktionalitet till klasshierarkier, utan att
man vill fylla klasserna med metoder som inte
verkar höra hemma där
– T.ex. kollisionsdetektion mellan olika figurer
● Lisps generiska funktioner löser det här
snyggare