Page History

...

Forestill deg en app for håndtering og avspilling av musikk. Når du bruker app'en vil den vite om alle sangene (eller låtene/stykkene/sporene...), albumene (eller cd'ene/lp'ene...), artistene (eller gruppene/orkestrene...) og spillelistene. Hver av disse kan representeres som objekter, altså sang-objekter, album-objekter og spilleliste-objekter. Hvert sang-objekt vil vite navnet på sangen, lengden, lyddataene som må spilles av og hvilket album det tilhører. Hvert album-objekt vil vite hvilke sanger det inneholder, hvem som har skrevet (komponist) og hvem som fremfører (artist) sangene (kanskje vil også sang-objektene inneholde informasjon om komponist og artist, siden de jo kan varierer variere på samme album). Sang- og album-klassene, på den annen side, kan ses på som (koden som bestemmer) reglene for hva slags type data hvert sang- og album-objekt kan inneholde og hvordan disse håndteres, f.eks. at ett og samme sang-objekt ikke kan tilhøre mer enn ett album-objekt. Klassen må også sørge for at koblingen mellom sang-objekter og album-objekter er konsistent, slik at det altid er slik at et sang-objekt ligger i sang-lista til albumet det tilhører.

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.

object "~#Imagine:Sang" as imagine {
	tittel = "Imagine"
	lyddata = 011011...
}

object "~#JohnLennon:Person" as johnLennon {
	navn = "John Lennon"
}
imagine -> johnLennon : "artist"

class Sang {
	String tittel
	byte[] lyddata
	setTitle(String)
	play()
}

class Person {
	String navn
	setNavn(String)
}

Sang -> Person : artist 

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).

...

Sider om objekter og klasser

Oppgaver om objekter og klasser

...

1) Det fremheves ofte som en fordel med objektorientert programmering at koden tilsvarer (er en modell av) virkeligheten og derfor faller naturlig å skrive. Dette er i beste fall en grov forenkling av problemetstillingen, f.eks. oppfatter ikke alle virkeligheten likt og et program vil dessuten ofte kreve objekter/kode som ikke svarer til virkeligheten. Vi skal ikke ta denne debatten her, og oppfordrer istedet programmerere til bevissthet og edruelighet omkring fordeler og ulemper ved OOP i forhold til andre paradigmer.

...