...
Observert-rollen | Observatør-rollen |
---|---|
Det observerte objektet må være observerbart, dvs. ha metoder for å
I tillegg kan det ofte være lurt å ha en metode 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. |
...
|
|
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.
Sidetype | Ferdig | Dekningsgrad | Omfang |
---|---|---|---|
teori | 75 | 75 | 75 |
...