Eksamenssett logo
eksamenssett.noTren målrettet
  • Ungdomsskole/VGS
  • Høyskole
  • Ressurser
  • Skolenyttig
eksamenssett.noTren målrettet

Komplett samling av eksamensoppgaver og løsninger for norsk skole.

Om ossPrivatundervisningPriserSlik bruker du sidenFAQPersonvernVilkårAngrerettKontaktKI-deklarasjon

© 2026 Eksamenssett.no · Alle rettigheter forbeholdt

Innholdet er utviklet med KI og kvalitetssikres kontinuerlig – av modellene, og ved at våre tusenvis av brukere kan melde fra om feil. Slik jobber vi med kvalitet →

Eksamenssett.no eies og drives av Studenthjelp Privatundervisning AS

Org.nr. 913 117 387 (Foretaksregisteret) · Aksel Olsens vei 10B, 1597 Moss · Ikke MVA-registrert

Eksamenssett logo
eksamenssett.noTren målrettet
  • Ungdomsskole/VGS
  • Høyskole
  • Ressurser
  • Skolenyttig
eksamenssett.noTren målrettet

Komplett samling av eksamensoppgaver og løsninger for norsk skole.

Om ossPrivatundervisningPriserSlik bruker du sidenFAQPersonvernVilkårAngrerettKontaktKI-deklarasjon

© 2026 Eksamenssett.no · Alle rettigheter forbeholdt

Innholdet er utviklet med KI og kvalitetssikres kontinuerlig – av modellene, og ved at våre tusenvis av brukere kan melde fra om feil. Slik jobber vi med kvalitet →

Eksamenssett.no eies og drives av Studenthjelp Privatundervisning AS

Org.nr. 913 117 387 (Foretaksregisteret) · Aksel Olsens vei 10B, 1597 Moss · Ikke MVA-registrert

Eksamenssett logo
eksamenssett.noTren målrettet
  • Ungdomsskole/VGS
  • Høyskole
  • Ressurser
  • Skolenyttig
eksamenssett.noTren målrettet

Komplett samling av eksamensoppgaver og løsninger for norsk skole.

Om ossPrivatundervisningPriserSlik bruker du sidenFAQPersonvernVilkårAngrerettKontaktKI-deklarasjon

© 2026 Eksamenssett.no · Alle rettigheter forbeholdt

Innholdet er utviklet med KI og kvalitetssikres kontinuerlig – av modellene, og ved at våre tusenvis av brukere kan melde fra om feil. Slik jobber vi med kvalitet →

Eksamenssett.no eies og drives av Studenthjelp Privatundervisning AS

Org.nr. 913 117 387 (Foretaksregisteret) · Aksel Olsens vei 10B, 1597 Moss · Ikke MVA-registrert

TDT4100

Cheat Sheet

Formler, begreper og oppsummering
Objektorientert programmering
eksamenssett.no

Nøkkelformler per tema

Klasser og objekter

  • •public class Navn { felt; konstruktor; metoder } — klassedefinisjon
  • •public Navn(...) { this.felt = parameter; } — konstruktor (ingen returtype)
  • •this(...) som første linje — kall til annen konstruktor i samme klasse
  • •private static int teller = 1; + this.num = teller++; — automatisk lopenummer
  • •public static void main(String[] args) — programmets startpunkt
  • •Typevalg: id i String, store beløp i long, prosent/desimaltall i double

Innkapsling og tilgangskontroll

  • •private (kun klassen) · pakke-privat (samme pakke) · protected (subklasser+pakke) · public (alle)
  • •private final T felt; — uforanderlig felt, settes kun i konstruktor
  • •if (ugyldig) throw new IllegalArgumentException("..."); — validering
  • •return new ArrayList<>(internListe); — returner kopi, ikke referansen
  • •Konstruktør bør kalle setter slik at validering ikke dupliseres

Arv og polymorfisme

  • •class Sub extends Super { ... } — arv
  • •super(args); — kall til superklassens konstruktor, må stå FØRST
  • •super.metode() — kall til overstyrt metode i superklassen
  • •@Override — markerer (og lar kompilator sjekke) overstyring
  • •Polymorfi: faktisk objekttype, ikke deklarert type, avgjør hvilken metode som kjøres
  • •(Type) obj — cast; ClassCastException ved kjøretid hvis feil type

Grensesnitt og abstrakte klasser

  • •interface Navn { metode(); } + class K implements Navn { ... }
  • •abstract class Navn { abstract T m(); /* + ferdige metoder */ }
  • •Funksjonelt grensesnitt = nøyaktig én abstrakt metode → kan brukes som lambda
  • •Iterable<T>: Iterator<T> iterator() → for-each-støtte
  • •Comparable<T>: int compareTo(T o) (neg/0/pos) → Collections.sort
  • •Comparator<T>: (a,b) -> ... → alternativ sortering

Generics og collections

  • •Collection<E> c = new ArrayList<>(); — deklarer mot grensesnitt, instansier klasse
  • •List (ordnet, indeks, duplikater) · Set (unik, uordnet) · Map<K,V> (nøkkel→verdi)
  • •for (E e : samling) { ... } — for-each-iterasjon
  • •Iterator<E> it = c.iterator(); it.hasNext(); it.next(); it.remove(); — trygg fjerning
  • •c.iterator().next() — hent første element av en generell Collection
  • •c.stream().filter(...).map(...).sum()/collect(...) — Stream-teknikken

Unntakshåndtering

  • •throw new IllegalArgumentException("melding"); — kast ved ugyldig argument
  • •try { ... } catch (Type e) { ... } — fang og håndter
  • •... metode(...) throws IOException { ... } — deklarer sjekket unntak
  • •Usjekket: subklasser av RuntimeException (ingen throws nødvendig)
  • •Sjekket: f.eks. IOException (må fanges eller deklareres)
  • •Bruk mest spesifikke unntakstype, ikke generell Exception

Designmønstre

  • •Observatør: lytter-grensesnitt + Collection av lyttere + add/remove + fire-metode
  • •Fire-metoden må kalles HVER gang den observerte tilstanden endres
  • •Lytter: class X implements Lytter + kilde.addLytter(this) i konstruktør
  • •Delegering: private Grensesnitt delegat; + videresend kall + setter for å bytte
  • •Komposisjon: bygg sammensatt oppførsel av enkle objekter (Relation2(rel1, rel2))

Testing og feilsøking

  • •assertEquals(forventet, faktisk); — likhet via equals (forventet først)
  • •assertTrue(uttrykk); / assertFalse(uttrykk); — boolsk sjekk
  • •assertTrue(a == b); — sjekk identitet (samme objekt), ikke assertEquals
  • •Pakke-privat hjelpemetode → lettere å rigge opp testtilstand
  • •Tracing: følg fortegn, indeks (0 vs 1) og utilsiktede bivirkninger
  • •Diagrammer: objekttilstand (før/etter) ≠ objektdiagram (referanser) ≠ klassediagram (UML)

Vanlige feil å unngå

Klasser og objekter

  • •Gir konstruktøren en returtype (f.eks. void) — da er det en vanlig metode, ikke en konstruktør
  • •Glemmer this. når parameter og felt har samme navn — feltet blir aldri satt
  • •Bruker int til store pengebeløp som kan overstige ~2,1 mrd. — bør være long
  • •Lar feltet være vanlig (instans) når det skulle vært static (delt teller) — hvert objekt starter da på 1
  • •Begrunner ikke typevalg — sensor forventer en kommentar om hvorfor du valgte String/long/double

Innkapsling og tilgangskontroll

  • •Gjør felt public — da kan hvem som helst sette ugyldige verdier uten validering
  • •Returnerer den interne lista direkte; kallende kode kan da mutere objektets innside
  • •Bare en if rundt initialiseringen i stedet for å kaste unntak — kravet er som regel å UTLØSE unntak
  • •Lager get/set for alt rutinemessig; settere bør utelates når feltet kun settes i konstruktøren
  • •Forveksler protected og private — protected gir også subklasser og pakke tilgang

Arv og polymorfisme

  • •Glemmer super(...) som første linje i subklassens konstruktør — kompileringsfeil
  • •Overstyrer en metode men endrer signaturen litt; uten @Override blir det en ny metode i stedet
  • •Tror variabelens deklarerte type avgjør metodevalg — det er objektets faktiske type (polymorfi)
  • •Bruker arv der oppførsel egentlig burde kunne byttes dynamisk (delegering er mer fleksibelt)
  • •Caster uten å vurdere at feil faktisk type gir ClassCastException ved kjøretid

Grensesnitt og abstrakte klasser

  • •Tror en klasse bare kan implementere ett grensesnitt — den kan implementere flere
  • •Velger abstrakt klasse når man trenger flere kontrakter — kun ÉN superklasse er lov
  • •compareTo som returnerer boolean eller alltid 1/-1 — den skal returnere negativt/0/positivt
  • •Glemmer at Iterable-implementasjon krever iterator()-metoden for at for-each skal virke
  • •Beskriver funksjonelt grensesnitt kun som «én metode» uten å nevne kravet om forutsigbart resultat

Generics og collections

  • •Prøver å instansiere grensesnittet: new Collection<>() / new List<>() — ulovlig
  • •Velger List når Set passer bedre (unngår duplikater gratis) eller omvendt
  • •Fjerner elementer i en for-each-løkke — gir ConcurrentModificationException; bruk iterator.remove()
  • •Antar at en Collection har get(0); bruk iterator().next() for første element
  • •Glemmer å initialisere samlingsfeltet (forblir null) — NullPointerException ved første bruk

Unntakshåndtering

  • •Bruker en if rundt initialiseringen i stedet for å kaste unntak når regelen brytes
  • •Svelger unntak i tomt catch-blokk og skjuler reelle feil
  • •Fanger generell Exception der en spesifikk type (IOException, NumberFormatException) er riktig
  • •Glemmer throws på metoder som bruker strømmer (IOException) — kompileringsfeil
  • •Forveksler IllegalArgumentException (ugyldig argument) med IllegalStateException (ulovlig tilstand)

Designmønstre

  • •Gjør klassen observerbar men glemmer å kalle fire-metoden fra ALLE metoder som endrer tilstanden
  • •Itererer over lytter-/kø-lista og fjerner med samling.remove(...) i stedet for iterator.remove()
  • •Forveksler observatør (varsle om endring) med delegering (videresende en oppgave)
  • •Lar den observerte kjenne den konkrete lytterklassen i stedet for bare lytter-grensesnittet
  • •Glemmer at lytteren må melde seg PÅ (addListener) før den får varsler

Testing og feilsøking

  • •Bytter om argumentene i assertEquals — forventet verdi skal stå først
  • •Bruker assertEquals der man egentlig vil sjekke identitet (==) med assertTrue
  • •Lar testene avhenge av hverandre i stedet for å rigge opp egen tilstand i hver test
  • •Av-for-én-feil: glemmer at lister er 0-indekserte mens nummerering ofte starter på 1
  • •Skriver hasNext() med bivirkning (flytter iterator) — bryter kontrakten om gjentakbare kall

Eksamenstips

Klasser og objekter

  • •Del 1 er nesten alltid en verdiklasse: skriv konstruktør + get-metoder, gjør felt private final
  • •static-teller for løpenummer er et tilbakevendende triks — øv på Table-/Konto-mønsteret
  • •Begrunn datatype-valg eksplisitt i kommentar; det gir poeng på teoridelen
  • •Husk at du kan bruke metoder fra tidligere deloppgaver selv om du ikke fikk dem helt riktige

Innkapsling og tilgangskontroll

  • •På teorispørsmål om modifikatorer: begrunn ALLTID hvorfor (skjuling, invariant, arv, testbarhet)
  • •Validering skal kaste unntak (vanligvis IllegalArgumentException), ikke bare ignorere stille
  • •Pakke-privat tilgang nevnes ofte som triks for å gjøre en klasse lettere å teste
  • •final på felt signaliserer verdiklasse og hindrer utilsiktet endring — bruk det aktivt

Arv og polymorfisme

  • •Standardgrep i Del 3: identifiser felles kode, lag abstrakt superklasse, la subklasser kalle super(...)
  • •Drøft arv vs. delegering — delegering byttes ved kjøretid og er mer fleksibel; dette gir poeng
  • •Bruk alltid @Override; det fanger signaturfeil og signaliserer hensikten til sensor
  • •Husk at en abstrakt superklasse kan ha både ferdige (felles) metoder og abstrakte (varierende) metoder

Grensesnitt og abstrakte klasser

  • •Spørsmål «er X et funksjonelt grensesnitt?» kommer ofte — svar: én abstrakt metode + samme input gir samme output
  • •Lambda-syntaks for et funksjonelt grensesnitt er gjenganger (f.eks. Relation/Predicate/Comparator)
  • •Vis at du kan implementere Comparable for naturlig ordning OG Comparator for alternativ sortering
  • •Drøft grensesnitt vs. abstrakt klasse med begrunnelse (flere kontrakter vs. delt implementasjon)

Generics og collections

  • •Begrunn valget List vs. Set vs. Map — det er et fast poeng (trenger du indeks? duplikater? oppslag?)
  • •Deklarer alltid mot grensesnitt-typen (Collection/List/Map), instansier ArrayList/HashSet/HashMap
  • •Mange sett ber om en Stream-versjon av en løkke i en diverse-del — øv på filter/map/anyMatch/sum
  • •Map<...> brukes ofte i stedet for to parallelle lister; nevn det som elegant alternativ

Unntakshåndtering

  • •Konstruktørvalidering med IllegalArgumentException er gjenganger — vis at du UTLØSER unntak
  • •På IO-oppgaver: deklarer throws IOException framfor å fange og ignorere; begrunn valget
  • •Forklar hvorfor man bør bruke spesifikk unntakstype og ikke svelge unntak — gir teoripoeng
  • •multi-catch (catch (A | B e)) er en ryddig måte å håndtere flere forventede unntak på

Designmønstre

  • •Observatør–observert er fast tema i siste del — kan de fire delene (grensesnitt, liste, add/remove, fire) utenat
  • •Delegering brukes som «mer fleksibelt alternativ til arv» — vis setter som bytter delegat ved kjøretid
  • •Når du behandler en kø under varsling, bruk iterator.remove() for trygt å fjerne plasserte elementer
  • •Komposisjon (Relation2-mønsteret) lar deg bygge nye relasjoner uten nye klasser — nevn dette poenget

Testing og feilsøking

  • •Spørsmål om JUnit kommer ofte: én assert per krav, riktig opprigging, og forklar testteknikken
  • •Når du blir bedt om å gjøre en klasse testbar, foreslå en pakke-privat hjelpemetode
  • •Tracing-oppgaver: skriv ned variablenes verdier steg for steg — det avslører plantede feil
  • •Kjenn forskjellen på objekttilstandsdiagram, objektdiagram og klassediagram; eksamen blander dem bevisst
eksamenssett.no · TDT4100 Objektorientert programmering