...
En måte å illustrere oppførselen på er et diagram over hvordan tilstanden til objektet utvikler seg over tid, når ulike metoder blir kalt.
| PlantUML Macro |
|---|
object "Counter" as counter1 {
counter = 1
end = 3
}
counter1 - |
|
...
-> counter1 : getCounter() => 1
object "Counter" as counter2 {
counter = 2
end = 3
}
counter1 - |
|
...
-> counter2 : count()
counter2 - |
|
...
-> counter2 : getCounter() => 2
object "Counter" as counter3 {
counter = 3
end = 3
}
counter2 - |
|
...
-> counter3 : count()
counter3 - |
|
...
-> counter3 : getCounter() => 3
counter3 - |
|
...
...
| samme Counter-objekt går fra én tilstand (verdiene til counter og end) til en annen, |
...
...
| og count-operasjonene utføres. Hver boks er altså det samme objekt i ulike tilstander og pilene angir hvilket kall som leder til samme eller neste tilstand. Kallene |
...
...
| endrer ikke noen verdier, så derfor leder de til samme tilstand. Kallene |
...
| til count, derimot, endrer telleren (counter) inntil den når slutt-verdien og gir en (heldigvis endelig) kjede med tilstander (se fotnote 1). |
Generelt er tilstanden til et objekt verdien av alle attributtene, mens oppførselen er når en kan kalle de ulike operasjonene, hvilke argumenter som er gyldige og hva de returnerer og hvordan tilstanden endres av dem. I eksemplet er det alltid tillatt å kalle begge operasjonene, men en kunne tenke seg at count tok et argument som anga hvor mye telleren skulle økes og at det var ulovlig (å prøve) å øke telleren forbi slutt-verdien. Dette gir en annen oppførsel, som er forsøkt illustrert i diagrammet under.
| PlantUML Macro |
|---|
object "Counter" as counter1 {
counter = 1
end = 3
}
object "Counter" as counter2 {
counter = 2
end = 3
}
counter1 --> counter2 : count(1)
object "Counter" as counter3 {
counter = 3
end = 3
}
counter2 -right-> counter3 : count(1)
counter1 -right-> counter3 : count(2) |
| Vi ser at ett kall |
...
...
| har samme effekt som to kall |
...
...
| og at det ikke lenger er lov å kalle count i den siste tilstanden, dsv. når telleren (counter) har nådd slutt-verdien (end). Kall |
...
...
| er utelatt, siden de (fortsatt) ikke endrer tilstand. |
For den som bruker et objekt (eller klasse) er det viktig å vite hvordan et objekt oppfører seg, både for å vite om objektet passer til (løser) problemet og hvordan unngå å bruke det feil. For den som skal kode oppførselen i en klasse, er det selvsagt helt vesentlig å tenke gjennom hvilken oppførsel objektene skal ha, og eksempler som den i figurene er ofte nyttige, både for å tenke gjennom problemet før en koder og for å forklare andre hvordan koden virker (eller er ment å virke). Slike eksempler hjelper en også å skrive tester, som forklart i Oppførsel og enhetstesting.
...
