...
Sang-objekt | Sang-klasse |
---|
Konkrete data om bestemt sang: - Tittel: Imagine
- Artist: John Lennon
- Lyddata: 011011...
Kan gjøre følgende beregninger/operasjoner på sine data | Beskriver strukturen til alle Sang-objekter: - Tittel: tekst
- Artist: referanse til Person-objekt
- Lyddata: binære tall
Kode for beregninger/operasjoner - setTitle - endrer tittel
- play - spiller av lyd-dataene
|
En bruker gjerne å visualisere både objekter og klasser i diagrammer. Siden objekter eksisterer ved kjøring av programmer, mens klasser er koden vi skriver, så bruker vi å vise dem i hver sine diagrammer, henholdsvis objektdiagrammer og klassediagrammer. I tabellen under er begge typen diagrammer vist. Til venstre vises to objekter, hvor den ene (Imagine-sangen) refererer til den andre (John Lennon-personen). Til høyre vises to klasser med hvilke data det er lov å knytte til objekter av de to typene, inkludert referanser dem imellom.
Objekter | Klasser |
---|
| Imagine~#Imagine:Sang" as imagine {
tittel = "Imagine"
|
| artist | John Lennon
lyddata = 011011...
}
011011...
}
object "~#JohnLennon:Person" as johnLennon {
navn = "John Lennon"
}
imagine -> johnLennon : "artist" |
|
PlantUML Macro |
---|
class Sang {
String tittel
|
| Person artist
| = 011011
setTitle(String)
play()
}
class Person {
String navn
setNavn(String)
}
|
| imagine | ..|> Sang
|
Oppdelingen av tilstanden til det kjørende programmet i objekter og av programkoden i klasser bestemmes av programmereren. Det er ofte ønskelig at strukturen av objekter tilsvarer/speiler vår oppfatning av virkeligheten, slik at strukturen av objekter/kode blir lettere å tenke ut/skrive og forstå/lese. Derfor er det viktig å være godt kjent med problemområdet før en setter seg ned og programmerer, i tillegg til at en kan generelle kodingsteknikker (se fotnote 1).
...