...
Observert-rollen | Observatør-rollen |
---|---|
Det observerte objektet må være observerbart, dvs. ha metoder for å
| Observatøren må ha metoder for å
Akkurat når og hvordan observatøren blir registrert hos det observerte objektet er ikke gitt, det vesentlige er hva som skjer etterpå: at observatøren får beskjed om tilstandsendringer. |
Eksempel: Vintersportssted og pudderalarm
For å gjøre teknikken konkret, så tenker vi oss at et vintersportssted, f.eks. Oppdal, tilbyr seg å sende ut varsel om større mengder nysnø, såkalt pudderalarm, slik at skientusiastiske studenter (og faglærere) vet når de skal prioritere løssnøkjøring fremfor forelesninger. Her fungerer vintersportsstedet som observert og skientusiasten som observatør. For å implementere dette definerer vi derfor klassene Vintersportssted og Person. I tillegg, og dette er viktig, så defineres grensesnittet Pudderalarmlytter, som fanger opp det å være interessert i pudderalarm. Dette gjør koblingen mellom Vintersportssted og Person litt løsere og åpner for at andre klasser, f.eks. Rutebilselskap også kan vise sin interesse for pudderalarm og sette opp ekstrabusser til det aktuelle vintersportsstedet.
|
Iht. observert-rollen må Vintersportssted har metoder for å registrere
For at klassen for det observerte objektet ikke skal være bundet til en spesifikk observatør, så defineres gjerne et grensesnitt som observatørene må implementere.
Diagrammet til venstre viser hvordan klassene henger sammen og hvilke metoder de implementerer. Pudderalarmlytter-grensesnittet definerer én metode, som kalles når pudderalarmen går. Den kalles av Vintersportssted og implementeres av klassene som ønsker å reagere på pudder-tilstanden. Vintersportssted har to metoder for å håndtere lytterne: én for å legge til og én for å fjerne Pudderalarmlytter-e. I tillegg har den en intern metode for å si fra til lytterne, som må kalles når pudder-tilstanden inntreffer. En slik metode er ikke påkrevd, men gir ryddigere kode når det er flere metoder som endrer tilstanden det skal varsles om. Person og Rutebilselskap er klasser som ønsker å reagere på pudderalarmen, og derfor må de implementere Pudderalarmlytter-grensesnittet. Dette krever at de implementerer pudderalarm-metoden, men akkurat hva de gjør er opp til dem. Rutebilselskap kan f.eks. endre på rute- og bemanningsplanen for å gi rom for ekstrabusser og Person kan f.eks. kanselere alle avtaler og bestille bussbillett. Merk at pudderalarm-metoden får det aktuelle Vintersportssted-et som argument, slik observatørene (lytterne) kan reagere riktig. Rutebilselskap-et må f.eks. sette opp ekstrabusser til riktig sted og Person må bestille riktig bussbillett. Koden nedenfor er en standard implementasjon av tilfellet som er beskrevet her. En mer abstrakt illustrasjon av teknikken er gitt som eksempel på arv i klassediagrammer. |
|
|
Sidetype | Ferdig | Dekningsgrad | Omfang |
---|---|---|---|
teori | 75 | 75 | 75 |
Registrering og oppdatering er en del av