6.1 Fra spesifikasjon til klasser — modelleringsmetoden

Framgangsmåten: stryk under hvert substantiv i teksten, og spør om det er en
ting med egenskaper eller bare en egenskap.

Bok har tittel, forfatter og utlånsstatus — det er en ting. Tittel har ingen
egenskaper; det er en egenskap. Altså blir Bok en klasse og _tittel en instansvariabel.

En god tommelfingerregel: kan du tenke deg flere av den, og har hver av dem sine egne opplysninger, er det en klasse.

Eksamensoppgavene har typisk tre til fem klasser. Har du funnet to, har du sannsynligvis slått sammen noe; har du funnet åtte, har du gjort egenskaper om til klasser.

Hver egenskap teksten nevner om en ting, blir en instansvariabel satt i konstruktøren.

To slag: de som kommer utenfra og står som parametere
(def __init__(self, tittel, forfatter):), og de som har en startverdi
(self._utlaant = False, self._antall_utlaan = 0, self._boker = {}).

Den andre gruppen er den som oftest glemmes. Kjenn den igjen på formuleringer som
«starter på null», «er ikke utlånt når den registreres» og «har ingen bøker til å begynne med».

Alt objektet skal huske, settes i __init__. Ingen unntak.

Hver «kan gjøre»-setning i teksten blir en metode.

«En bok kan lånes ut» gir laan_ut(self). «Biblioteket kan finne en bok på tittel» gir finn(self, tittel). Trenger metoden en verdi utenfra, blir den en parameter.

Metodenavnene skrives med små bokstaver og gjerne som verb: laan_ut,
legg_til, finn, meld_paa. Norske navn er fasitens egen stil — bare uten æ, ø og å.

Ligger metoden på riktig klasse? Spør hvem som eier opplysningene den
trenger. Utlånsstatusen ligger i Bok, så laan_ut hører hjemme der — ikke i
Bibliotek.

Klassene med instansvariabler og metodesignaturer, men uten ferdige metodekropper:

class Rett:
    def __init__(self, navn, pris):
        # setter _navn, _pris, _solgte = 0

    def selg(self, antall):
        # oeker _solgte

    def omsetning(self):
        # returnerer pris ganger solgte

Blokken er et skjelett med kommentarer i stedet for kode, og er derfor merket som ikke-kjørbar — Python krever en kropp i hver metode.

Skjelettet er verdt poeng i seg selv. Rekker du ikke å fylle inn alle kroppene, viser det likevel at du har forstått modellen, og deloppgavene rettes hver for seg.

På kladdepapiret holder det med enda mindre: klassenavn, en strek under, og
metodenavnene i en liste.

Navnet på en metode pluss parameterne den tar: selg(self, antall).

Signaturen er det den som kaller, trenger å vite. Er den riktig, kan resten av programmet skrives selv om kroppen er tom — og på eksamen kan du bruke en metode oppgaveteksten beskriver uten selv å ha rukket å skrive den.

Det er en av de viktigste taktiske rådene i hele boka: stå aldri fast. Sier oppgaven at klassen har en metode hent_ledige(), kan du kalle den i deloppgave d) selv om du hoppet over den i deloppgave b).

Hvor mange objekter av den ene klassen hvert objekt av den andre er knyttet til.

To former, og bare to i denne boka:

- Én-til-én: instansvariabelen peker på ett objekt.
self._eier = person.
- Én-til-mange: instansvariabelen er en samling av objektreferanser.
self._boker = [] eller self._boker = {}.

Les teksten sakte. «Hvert stativ har en samling sykler» er én-til-mange. «Hver konto har en eier» er én-til-én.

Ordene som avslører én-til-mange: flere, en samling, alle, hver av, flertallsform.

Valget innenfor én-til-mange, og det avgjøres av ett spørsmål: skal noe slås opp på et navn eller en kode?

Er svaret ja — «finne en bok på tittel», «hente salen med et gitt navn» — er det en ordbok, med navnet som nøkkel og objektet som verdi.

Er svaret nei — du skal bare gå gjennom alle, telle eller skrive ut — er en
liste enklere.

I tvil: begynn med en liste. Å lete gjennom en liste med en løkke er alltid mulig, og det gir uttelling. Ordboka er bare raskere og ryddigere når oppslaget er hovedjobben.

Samlingen skal holde objektene, ikke opplysninger om dem.

self._boker.append(bok) — ikke self._boker.append(bok.hent_tittel()).

Grunnen er at du mister metodene. Har du bare titlene, kan biblioteket ikke lenger be en bok om å låne seg ut, skrive seg selv eller si hvem forfatteren er — og alle de neste deloppgavene faller sammen.

Det er en av de faste vurderingene i Oppgave 4, og den dyreste enkeltbeslutningen i hele oppgaven.

Eksamensoppgavene er ofte underspesifiserte med vilje, og egne rimelige forutsetninger er uttrykkelig tillatt — så lenge de dokumenteres.

Skriv én kommentarlinje der valget tas:

class Stativ:
    def __init__(self, navn, plasser):
        # forutsetter at et stativ ikke kan ha null plasser
        self._navn = navn self._plasser = plasser self._sykler = []

s = Stativ("Blindern", 12)
print("ok")

Utskrift:

ok

Dette er den ene legitime bruken av kommentarer i en besvarelse. Ellers
skriver boka ingen kommentarer: ingen som gjentar hva koden gjør, og ingen overskrifter.

Typiske ting å dokumentere: hva som skjer ved en manglende nøkkel, om en verdi kan være negativ, om en klasse teksten så vidt nevner, er tatt med eller ikke.

I et virkelig program legges hver klasse i sin egen fil, og filene hentes inn med en linje øverst i programmet:

from bok import Bok from bibliotek import Bibliotek

Blokken er merket som ikke-kjørbar: den forutsetter to filer som ikke finnes her.

Denne boka skriver alle klassene i samme blokk, slik at hvert eksempel kan
kjøres nøyaktig som det står. På eksamen er det heller ingen som teller filer — det som rettes, er klassene og metodene.

Nevner oppgaveteksten filstrukturen, skriv en kommentar om at hver klasse hører hjemme i sin egen fil. Det er nok.

Oppgave 4 er delt i seks–sju deloppgaver, og hver av dem rettes for seg.

Konsekvensen er taktisk og viktig: stå aldri fast. Får du ikke til deloppgave c), hopp til d) — den rettes uansett, og den bygger sjelden på at c)
er skrevet.

Og du kan bruke en metode oppgaveteksten beskriver selv om du ikke har rukket å skrive den. Sier teksten at Bok har hent_tittel(), kall den. Sensor vet at den finnes, fordi oppgaven sa det.

Riktig struktur belønnes selv med småfeil. En løkke med en indeksfeil, en
glemt aksessor eller en litt klønete betingelse trekker lite når modellen er riktig.

Den tekstlige beskrivelsen Oppgave 4 starter med — noen få avsnitt som forteller hvilke ting som finnes, hva de har, og hva de kan gjøre.

Den ser ut som løpende tekst, men er en oppskrift. Substantivene gir klassene, egenskapene gir instansvariablene, «kan gjøre»-setningene gir metodene.

Les den to ganger før du skriver noe. Første gang for å forstå domenet, andre gang med blyant for å stryke under.

Å komme fra spesifikasjonen til et klasseoppsett: hvilke klasser, hva hver av dem husker, hva de kan gjøre, og hvordan de er knyttet sammen.

Det er det første steget i Oppgave 4, og det avgjør de seks–sju deloppgavene under. Bommer du her, drar feilen med seg alt.

Steget tar tre–fire minutter og er verdt poeng i seg selv — selv om du ikke rekker å fylle inn alle metodekroppene.

Hvert substantiv som er en ting med egne egenskaper, blir en klasse.

Bok har tittel og forfatter — en ting. Tittel har ingen egenskaper — en
egenskap.

Tommelfingerregelen: kan du tenke deg flere av den, og har hver av dem sine egne opplysninger, er det en klasse. Eksamensoppgavene har typisk tre til fem.

Hver setning i spesifikasjonen som sier at noe kan gjøres, blir en metode.

«En bok kan lånes ut» gir laan_ut(self). «Klubben kan finne et spill på tittel»
gir finn_spill(self, tittel).

Trenger metoden en verdi utenfra, blir den en parameter. Metodenavn skrives med små bokstaver, gjerne som verb, på norsk uten æ, ø og å.

I den klassen som eier opplysningene metoden endrer.

Utlånsstatusen bor i Bok, så laan_ut hører hjemme der. Legger du den i
Bibliotek, må den røre bok._utlaant direkte — feilkode #11.

Spør «hvem sine tall er dette?», så plasserer metoden seg selv. Det er den enkleste av alle modelleringsreglene, og den som oftest avgjør et plasseringsspørsmål.

Klassene med instansvariabler og metodesignaturer, uten ferdige kropper.

Skriv det først, hver gang. Da ser du hele modellen før du bruker tid på detaljer, og du har allerede sikret poengene for strukturen.

På kladdepapiret holder klassenavn, en strek under, og metodenavnene i en liste.
Det tar ett minutt.

Hvor mange objekter av den ene klassen hvert objekt av den andre er knyttet til.

Én-til-én: self._eier = person — ett objekt.
Én-til-mange: self._boker = [] eller {} — en samling.

Ordene avgjør: «hver konto har en eier» mot «senteret har flere saler».
Les den setningen to ganger.

Ett spørsmål: skal noe slås opp på et navn eller en kode?

Ja: ordbok, med navnet som nøkkel og objektet som verdi. Nei: liste.

I tvil, velg liste. Å lete gjennom en liste med en løkke er alltid mulig og gir uttelling; ordboka er bare ryddigere når oppslaget er hovedjobben.

Samlingen holder objektene, ikke opplysninger om dem:
self._boker.append(bok), ikke self._boker.append(bok.hent_tittel()).

Lagrer du rådata, mister du metodene, og alle senere deloppgaver — «skriv ut alle», «finn den beste», «lån ut» — faller sammen.

Det er den dyreste enkeltbeslutningen i hele Oppgave 4.

Anti-mønsteret: to lister som holder opplysninger om det samme, og som må holdes i takt manuelt.

self._titler og self._forfattere virker helt til noen fjerner ett element fra den ene. Da påstår programmet at feil forfatter skrev boka — uten en eneste feilmelding.

Løsningen er alltid den samme: én klasse som holder begge opplysningene, og én liste av de objektene.

En instansvariabel som ikke kommer utenfra: self._solgte = 0,
self._utlaant = False, self._boker = [].

Kjenn dem igjen i teksten på «starter på null», «er ikke utlånt når den registreres» og «har ingen … til å begynne med».

De er det som oftest glemmes, og de er et selvstendig poeng. Uten dem finnes ikke variabelen, og første metode som leter etter den, stopper programmet.

Eksamensoppgavene er ofte underspesifiserte med vilje, og egne rimelige forutsetninger er uttrykkelig tillatt.

Dokumentér dem med én kommentarlinje der valget tas:
# forutsetter at et stativ ikke kan ha null plasser.

Typiske ting å dokumentere: hva som skjer ved en manglende nøkkel, om en verdi kan være negativ, og om en klasse teksten så vidt nevner, er tatt med.

Boka skriver ingen kommentarer, med ett unntak: den dokumenterte antakelsen.

Ingen kommentarer som gjentar hva koden gjør, ingen overskrifter, ingen seksjonsstreker. De tar plass og gir ingen uttelling.

Velskrevne metodenavn gjør jobben bedre enn en kommentar: hent_ledige() sier mer enn # regner ut ledige plasser.

I et virkelig program bor hver klasse i sin egen fil, og filene hentes inn med en linje øverst i programmet.

Denne boka skriver alle klassene i samme blokk, slik at hvert eksempel kan kjøres nøyaktig som det står.

På eksamen teller ingen filer. Nevner oppgaveteksten filstrukturen, skriv en kommentar om at hver klasse hører hjemme i sin egen fil.

Oppgave 4 er delt i seks–sju deloppgaver, og hver av dem rettes for seg.

Konsekvensen er taktisk: stå aldri fast. Får du ikke til c), hopp til d) — den rettes uansett.

Og du kan bruke en metode oppgaveteksten beskriver selv om du ikke har rukket å skrive den. Sier teksten at klassen har hent_ledige(), kall den.

En løkke med en indeksfeil, en glemt aksessor eller en litt klønete betingelse trekker lite når modellen er riktig.

Det motsatte gjelder også: perfekt skrevne metoder på en gal modell hjelper ikke, fordi feilen gjentar seg i hver deloppgave.

Bruk derfor de første minuttene på modellen, ikke på å pusse den første metodekroppen.

Skriv dem oppgaven faktisk bruker, ikke alle mulige.

En ytterklasse som setter inn i en ordbok, trenger elementets hent_navn(). En utskriftsmetode som delegerer, trenger ingen aksessor i det hele tatt.

En klasse med åtte unødvendige sett-metoder er dårligere enn en med to nødvendige: hver overflødig mutator åpner et hull i kontrollen.

En aksessor trenger ikke å returnere en lagret verdi — den kan regne den ut:
return self._kapasitet - len(self._paameldte).

For den som bruker klassen, er det ingen forskjell, og det er poenget.
Grensesnittet lover et tall, ikke en bestemt lagringsmåte.

Å regne ut i stedet for å lagre er dessuten tryggere: verdien kan aldri komme i utakt med de tallene den bygger på.

Størrelsen på en typisk Oppgave 4.

Har du funnet to, har du sannsynligvis slått sammen noe — se etter en «boks»
som er blitt til to instansvariabler i stedet for en klasse.

Har du funnet åtte, har du gjort egenskaper om til klasser. En Tittel-klasse med bare en tekst i seg er ren støy.

Modell, skjelett, kropper — i den rekkefølgen.

Modellen er tre–fire minutter med blyant. Skjelettet er ett minutt til. Først da begynner du å skrive kode, og da vet du hvor hver metode hører hjemme.

Motsatt rekkefølge — å skrive ferdig kode på den første klassen med én gang — er den vanligste tidsfellen i hele eksamen.