Objektorientert programmering forklart med eksempler i C#: fra idé til enkel modell

Objektorientert programmering kan virke abstrakt hvis du bare har sett teorien i en lærebok. Samtidig er det en av de viktigste måtene å strukturere kode på i moderne utvikling.

I denne artikkelen ser vi på hva objektorientert programmering faktisk betyr i praksis, med enkle eksempler i C#. Målet er at du skal forstå ideene godt nok til å bruke dem i egne små prosjekter.

Hva betyr “objektorientert” i praksis?

I objektorientert programmering (OOP) beskriver du problemet ditt som objekter som ligner ting i den virkelige verden: en kunde, en bestilling, en brukerprofil eller et produkt. Hvert objekt har data (egenskaper) og handlinger (metoder).

I stedet for å ha mange løse variabler og funksjoner, samler du det som hører sammen. Det gjør koden enklere å lese, endre og teste når prosjektet vokser.

Klasser og objekter: tenk “oppskrift” og “kake”

Enklasseer en mal eller oppskrift. Etobjekter en faktisk instans basert på den malen. I C# definerer du en klasse slik:

Eksempel: enkel klasse for en konto

public class Konto
{
public string Eier { get; set; }
public decimal Saldo { get; private set; }

public Konto(string eier)
{
Eier = eier;
Saldo = 0m;
}

public void SettInn(decimal beløp)
{
if (beløp <= 0) return;
Saldo += beløp;
}

public bool TaUt(decimal beløp)
{
if (beløp <= 0) return false;
if (beløp > Saldo) return false;
Saldo -= beløp;
return true;
}
}

Her erKontoen klasse. EgenskapeneEierogSaldoer data. MetodeneSettInnogTaUter handlinger du kan utføre på en konto.

Slik oppretter og bruker du objekter

Når du har en klasse, kan du lage objekter av den mednew-nøkkelordet. Hvert objekt har sine egne verdier.

Eksempel: opprette og bruke Konto

var minKonto = new Konto("Ola Nordmann");
minKonto.SettInn(1000m);
var vellykket = minKonto.TaUt(300m);

Nå finnes et faktisk objektminKonto. Du kan opprette flere kontoer, alle med sin egen saldo, uten å skrive om logikken for innskudd og uttak.

Innkapsling: skjul detaljer du ikke vil rote til

En viktig idé i OOP erinnkapsling.

Det betyr at du skjuler interne detaljer, og bare viser det som er trygt og nyttig å bruke utenfra. I C# gjør du dette medpublic,privateog andre tilgangsnivåer.

I eksempelet over erSaldodefinert slik:

public decimal Saldo { get; private set; }

Alle kan lese saldoen, men bare koden inne i klassen kan endre den. Du tvinger all endring til å gå gjennom metodeneSettInnogTaUt, der du kan validere beløp og hindre negative saldoer.

Hvorfor innkapsling gjør koden din tryggere

Uten innkapsling kunne enhver del av programmet skrevet noe slikt:

minKonto.Saldo = -5000m;

Det gir liten mening i en bankmodell. Når du begrenser skriving til saldo, blir det mye vanskeligere å ødelegge tilstanden ved et uhell.

Fordelene er blant annet:

• Mindre risiko for feil fordi viktig logikk samles i få metoder.
• Enklere feilsøking, du vet hvor du må lete hvis noe blir galt.
• Klarere “offentlig grensesnitt” for klassen, du ser raskt hva som er meningen at skal brukes.

Arv: gjenbruk logikk uten kopiering

Arvlar en klasse bygge videre på en annen. Du kan ha en generell klasse, og så mer spesialiserte varianter som arver egenskaper og metoder.

Eksempel: basisbruker og administrator

public class Bruker
{
public string Epost { get; set; }
public bool Aktiv { get; private set; } = true;

public void Deaktiver()
{
Aktiv = false;
}
}

public class AdminBruker : Bruker
{
public void TilbakestillPassord(Bruker målbruker)
{
if (!Aktiv) return;
// Logikk for å tilbakestille passord for målbruker
}
}

AdminBrukerhar alt en vanligBrukerhar, pluss ekstra funksjonalitet. Dette unngår duplisering, og du kan skrive felles regler ett sted.

Når bør du bruke arv, og når er sammensetning bedre?

Arv er nyttig når du virkelig har en “er en”-relasjon, somAdminBruker er en Bruker. Men det er lett å overdrive.

Hvis forholdet egentlig er “har en”, er det ofte bedre medsammensetning, det vil si at en klasse inneholder et felt av en annen klasse, i stedet for å arve fra den.

Eksempel: Konto som har en Eier

public class Person
{
public string Navn { get; set; }
}

public class Konto
{
public Person Eier { get; set; }
// resten som før
}

Her er det mer naturlig at Kontohar enPerson som eier, enn at Kontoer enPerson. Sammensetning gir ofte mer fleksibel og forståelig kode i lengden.

Grunnlaget for gode designvalg: ansvar per klasse

Et praktisk prinsipp i OOP er at hver klasse bør ha et tydelig og begrenset ansvar. Mange kaller dette “enkeltansvarsprinsippet”.

En typisk felle for nybegynnere er å lage én gigantisk klasse som håndterer alt: lagring, validering, visning og forretningslogikk. Det blir raskt vanskelig å teste og endre.

En bedre tilnærming er for eksempel:

• En klasse som representerer data og regler, for eksempelKonto.
• En egen klasse eller tjeneste som lagrer og henter Konto fra database eller fil.
• En annen del av programmet som presenterer data i konsoll eller på nettside.

Slik kommer du videre i dine egne prosjekter

Du trenger ikke et stort system for å øve på objektorienterte ideer. Start med noe lite og konkret, som en enkel oppgaveapp, et mini bibliotekssystem eller et bookingskjema for timeavtaler.

Et mulig steg-for-steg-opplegg kan være:

1. Beskriv tingene i systemet ditt med ord: “kunde”, “bestilling”, “produkt”.
2. Lag en klasse for hver ting med passende egenskaper.
3. Legg til metoder som utfører viktige handlinger, for eksempel “legg til vare i bestilling”.
4. Skjul intern logikk som ikke bør brukes direkte utenfra, med private felt og metoder.
5. Test i en liten konsollapplikasjon der du oppretter objekter og kaller metodene.

Jo oftere du gjør dette, desto mer naturlig blir det å “tenke i objekter” når du løser problemer med kode.