Page History

...

class Vintersportssted {

	...
	// felt og metoder for å håndtere vær- og føre-tilstanden
	// endringsmetoder må kalle firePudderalarm() når pudder-tilstanden inntreffer
	...

	private Collection<Pudderalarmlytter> pudderalarmlyttere = new ArrayList<Pudderalarmlytter>();

	public void addPudderalarmlytter(Pudderalarmlytter pudderalarmlytter) {
		pudderalarmlyttere.add(pudderalarmlytter);
	}

	public void removePudderalarmlytter(Pudderalarmlytter pudderalarmlytter) {
		pudderalarmlyttere.remove(pudderalarmlytter);
	}

	private void firePudderalarm() {
		for (Pudderalarmlytter pudderalarmlytter: pudderalarmlyttere) {
			pudderalarmlytter.pudderalarm(this);
		}
	}
}

interface Pudderalarmlytter {
	public void pudderalarm(Vintersportssted);
}

class Person implements Pudderalarmlytter {
	...
	@Override
	public void pudderalarm(Vintersportssted vintersportssted) {
		// kanselere avtaler og bestille buss til vintersportssted
	}
}

class Rutebilselskap implements Pudderalarmlytter {
	...
	@Override
	public void pudderalarm(Vintersportssted vintersportssted) {
		// sette opp ekstrabuss til vintersportssted
	}
}

Variasjoner i teknikken

Dette mønsteret er nyttig i mange sammenhenger og gjentar seg med noen variasjoner.

For observatøren er variasjonene knyttet til hvor kompleks tilstanden det varsles om er. I tilfellet over er tilstanden enten-eller, altså tilsvarende en logisk verdi, og dette er det enkleste tilfellet som kan forekomme. Men med mer kompleks tilstand, så vil også teknikken endres:

• Metoden som er definert i observatør/lytter-grensesnittet kan ha flere og mer komplekse parametre. For tilstand som er lagret som i felt, er det ikke uvanlig å ha før- og etter-tilstanden som egne parametre, i tillegg til objektet som ble endret. Denne varianten finnes f.eks. i JavaFX sitt ObservableValue-grensesnitt. En annen variant er å ha ett parameter, men dette er et såkalt hendelsesobjekt, som (inne)holder data om selve endringen, inkludert objektet som ble endret og detaljer om tilstanden. Dette er typisk for GUI-komponenter, som putter informasjon om hva brukeren har gjort i objekter som arver fra java sin EventObject-klasse.
• Observatør/lytter-grensesnittet kan ha flere metoder, for å si fra om ulike tilfeller/tilstander. Dette kan gjøre koden i klassene som implementerer grensesnittet ryddigere, fordi ulike tilfeller håndteres av ulike metoder. Denne varianten finner en f.eks. i Java Swing sitt MouseListener-grensesnitt, som har separate metoder for å varsle om at brukeren trykker (mousePressed) og slipper (mouseReleased) musknappene.
• Observatør-rollen er noen ganger fordelt på flere grensesnitt. Dette gjøres når tilstanden det varsles om er kompleks, og en regner med at ulike klasser er interessert i ulike tilfeller og derfor vil finne det greiere å implementere et spesifikt grensesnitt med færre metoder. Denne varianten finner en f.eks. i Java Swing som har ulike grensenitt for musknapper (MouseListener) og musbevegelser (MouseMotionListener).

For den observerte er det færre variasjoner, men de som for observatøren også knyttet til kompleksiteten til tilstanden:

• Når det skal varsle til flere lytter-metoder, så har en gjerne flere fire-metoder.
• Når en skal varsle til flere lytter-grensesnitt, så har en gjerne flere lytterlister og add/remove-metoder. Alternativet er å ha et grensesnitt som de spesifikke grensesnittene arver fra, men dette gjør klassehierarkiet mer komplekst og bør unngås.

...