Objekter og klasser

Objekter og klasser er de sentrale begrepene i Objektorientert programmering, og kan oppfattes som to sider av samme sak. Objekter eksisterer ved kjøring av programmer, mens klasser er koden som styrer hvordan objektene oppfører seg. Objekter kan ses på som en måte å dele opp tilstanden til et kjørende program i logiske enheter, mens klasser kan ses på som en måte å dele opp koden i (tilsvarende) logiske enheter. Koden i hver klasse bestemmer hvordan tilstanden til en bestemt type objekt eller datakapsel oppfører seg, dvs. utvikler seg over tid.

En godt forestille seg et objekt som et vesen, f.eks. en liten gnom med en liten tavle. På tavla kan gnomen skrive ned alt han må huske på, og dette tilsvarer tilstanden til objektet. Akkurat hva som står på tavla, dvs. hvordan tilstanden er representert, holder gnomen for seg selv, men du kan stille gnomen spørsmål om tilstanden og på den måten få innblikk i det. I tillegg kan du be gnomen om å oppdatere det som står på tavla, f.eks. øke et tall, legge til en tekst osv. For hver type gnom finnes det regler for hva du kan spørre om når og hvordan gnomen skal håndtere forespørslene, og dette sikrer at tilstanden alltid er gyldig. Alt dette utgjør gnomens (eller objektets) oppførsel og er beskrevet i en instruks som deles av alle gnomer av samme type. Du har sikkert allerede skjønt at instruksen tilsvarer klassen. Noen gnomer er mest opptatt av å huske og håndtere data, de er data- eller tilstandsorienterte, mens andre husker lite, men har til gjengjeld mange ferdigheter og kan kalles tjenesteorientert.

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

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

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.