6.2 Flere samarbeidende klasser og «en-til-mange»

Bruk lista når du bare skal gå gjennom alle: skrive dem ut, telle dem, summere noe de svarer.

Rekkefølgen er den de ble lagt inn i, og du når dem både med for e in self._elementer: og med indeks self._elementer[0].

Skal du lete etter et bestemt element, må du løpe gjennom lista og sammenligne — det er fullt mulig og gir uttelling, men da er en ordbok som regel ryddigere.

class Sal:
    def __init__(self, navn):
        self._navn = navn

    def hent_navn(self):
        return self._navn

    def __str__(self):
        return "Sal " + self._navn

class Senter:
    def __init__(self):
        self._saler = {}

    def legg_til(self, sal):
        self._saler[sal.hent_navn()] = sal

s = Senter()
s.legg_til(Sal("Speilsal"))
s.legg_til(Sal("Spinning"))
print(len(s._saler))

Utskrift:

2

Utskriften bruker s._saler direkte, som boka ellers aldri gjør — feilkode
#11. Her er det gjort én gang for å vise at ordboka faktisk er fylt, siden
klassen ennå ikke har noen aksessor.

self._saler[sal.hent_navn()] = sal er den formen fasiten bruker: senteret
spør salen hva den heter, i stedet for å bestemme det selv.

Standardformen på en finn-metode, i tre linjer:

class Register:
    def __init__(self):
        self._d = {}

    def sett_inn(self, navn, verdi):
        self._d[navn] = verdi

    def finn(self, navn):
        if navn in self._d:
            return self._d[navn]
        return None

r = Register()
r.sett_inn("ada", 24)
print(r.finn("ada"))
print(r.finn("nora"))

Utskrift:

24
None

if navn in self._d: sjekker at nøkkelen finnes. return self._d[navn]
gir objektet. return None er det ærlige svaret når det ikke finnes noe.

Den som kaller, tester med if svar != None:. Det er tryggere enn å returnere en tom tekst eller -1, som begge kan forveksles med ekte data — feilkode #10, sentinel-kollisjon.

Verdien kommer inn i konstruktøren som en vanlig parameter, og settes med self._ som alt annet. Forskjellen er bare at den peker på et objekt i stedet for et tall eller en tekst.

Gevinsten er at modellen holder seg i takt: spør du
self._eier.hent_navn(), får du navnet slik det er nå. Lagrer du navnet som tekst i konstruktøren, blir det foreldet i det øyeblikket eieren skifter navn.

Det er en av de faste vurderingene i Oppgave 4.

Les det fra venstre: finn spillet, spør det om eieren, spør eieren om navnet.

Formen er ryddig så lenge kjeden er kort, og den er fasitens egen stil. Blir den lang, eller kan et ledd gi None, sett resultatet i en hjelpevariabel underveis:

    spill = klubb.finn_spill("Sjakk")
    if spill != None:
        print(spill.hent_eier().hent_navn())

Blokken er et utdrag og er merket som ikke-kjørbar.

Det er like god uttelling, og det er lettere å spore.

Forbindelsen der ett objekt er knyttet til mange av en annen klasse: et bibliotek med bøker, et senter med saler, en klubb med medlemmer.

I koden er den én linje i konstruktøren — self._elementer = [] eller {} — og én legg_til-metode.

Hver eneste Oppgave 4 i de seks moderne settene har minst én. Kjenn den igjen i teksten på ordene «flere», «en samling», «alle» og flertallsform.

Klassen hvis viktigste jobb er å holde mange objekter av en annen klasse.

Den kjennes igjen på fire trekk: en samling i konstruktøren, en legg_til, en eller flere metoder som løper gjennom samlingen, og som regel en finn.

Hver Oppgave 4 har minst én. Mønsteret er derfor verdt å kunne i fingrene — det er de samme fire bitene hvert år.

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. Biblioteket kan ikke lenger be en bok om å låne seg ut, skrive seg selv eller si hvem forfatteren er.

Det er den dyreste enkeltbeslutningen i Oppgave 4, fordi den slår ut i hver eneste senere deloppgave.

Containeren bestemmer ikke navnet, den spør objektet. Alternativet
sal._navn er feilkode #11, og det er den vanligste formen feilkoden tar når to klasser samarbeider.

Formen er også tryggere: endrer Sal hvordan navnet lagres, merker containeren ingenting.

Standardformen på finn, i tre linjer: sjekk med if navn in self._d:,
return self._d[navn], og return None ellers.

None er det ærlige svaret når det ikke finnes noe. Den som kaller, tester med
if svar != None:.

Alternativene — en tom tekst eller -1 — kan forveksles med ekte data. Det er feilkode #10, sentinel-kollisjon.

Å slå opp eller legge til på en nøkkel som ikke er opprettet.

To former: d[navn] uten sjekk, som stopper med KeyError og nøkkelen i meldingen. Og d[navn].append(x) når nøkkelen ikke finnes — samme feil, samme løsning.

Løsningen er alltid en if-sjekk foran: if navn in d: for oppslag,
if navn not in d: og d[navn] = [] for oppbygging.

Feilmeldingen du får når du kaller en metode på et søkeresultat som var None.

AttributeError: 'NoneType' object has no attribute 'hent_navn' betyr nesten alltid: et finn-kall fant ingenting, og du glemte å sjekke svaret.

Motgiften er if svar != None: hos den som kaller. Den er billig og fjerner hele feilklassen.

At ytterklassen ber underobjektet gjøre jobben, i stedet for å gjøre den selv.

Kjennetegnet i koden er en løkke der kroppen er ett kall på underobjektet, og ingen felt hentes ut med understrek.

Gevinsten er den samme som ved innkapsling: endrer underklassen hvordan den regner eller viser seg, merker ytterklassen ingenting.

Løkka over en ordbok gir nøklene, ikke objektene:

    for n in self._d:
        print(self._d[n])

Blokken er et utdrag og er merket som ikke-kjørbar.

Skriver du for e in self._d: print(e), får du nøklene skrevet ut som tekst — en klassisk sporingsfelle. Objektet må hentes med et oppslag.

En metode kaller aldri en metode med samme navn — verken på seg selv eller på et underobjekt.

Elementet har skriv(), containeren har skriv_alle(). Elementet har
antall(), containeren har totalt_antall().

To grunner: navnene beskriver ulike jobber, og en metode som ser ut som om den kaller seg selv, ligner på rekursjon, som er utenfor pensum i dette emnet.

Mønsteret for å summere noe underobjektene vet:

    def totalt_antall(self):
        total = 0 for e in self._elementer:
            total = total + e.antall()
        return total

Blokken er en mal og er merket som ikke-kjørbar.

Tre plasseringer avgjør: total = 0 før løkka, + inne i den, return
etter den. Det er nøyaktig samme mønster som i
kap. 3.1 — bare med et metodekall i stedet for en verdi.

Spør du self._eier.hent_navn(), får du navnet slik det er nå. Lagrer du navnet som tekst, blir det foreldet i det øyeblikket eieren skifter navn.

Det er en av de faste vurderingene i Oppgave 4, og det er lett å bomme på under tidspress.

Les fra venstre: finn spillet, spør det om eieren, spør eieren om navnet.

Kan et ledd gi None, del kjeden opp med en hjelpevariabel og en sjekk. Det er like god uttelling, og det er lettere å spore.

En utleie har mange stativer, og hvert stativ har mange sykler. Ytterklassen har en ordbok, hvert stativ en liste.

Det er helt vanlig i Oppgave 4, og hvert nivå følger nøyaktig samme mønster:
samling i konstruktøren, legg_til, løkke som delegerer.

Blander du nivåene — for eksempel ved å la utleien holde alle syklene direkte — mister du muligheten til å spørre «hvor mange står på Blindern?».

Et medlem kan stå i medlemslista og i ventelista samtidig, og et medlem kan være eier av to spill.

Da finnes det fortsatt bare ett objekt. Endring gjennom den ene veien sees gjennom den andre, og det er som regel nettopp det du vil.

len() teller referanser, ikke objekter. Spør en oppgave «hvor mange objekter er laget?», teller du klassenavn med parentes.

En ordbok kan aldri ha to like nøkler. Legger du inn samme navn to ganger,
overskrives det første objektet uten en advarsel.

Er det et problem, må oppgaven si hva som skal skje — og da er teller-idiomet eller en if-sjekk foran innsettingen svaret.

Er det ikke et problem, er overskrivingen ofte nettopp det som er ønsket: den nyeste opplysningen gjelder.

Den bryter konvensjonen sensor ser etter. Den dupliserer visningen, så to steder må endres når formatet skal endres. Og den binder ytterklassen til underklassens innside, slik at ingen av dem kan endres uavhengig.

Alternativet er én linje kortere: print(e).

Ordboka husker den rekkefølgen nøklene ble opprettet i — ikke når de sist ble endret, og ikke etter størrelse.

En delegeringsløkke over en ordbok skriver derfor ut i innsettingsrekkefølge, og det er verdt å vite når du skal spore en utskrift.

Skal noe sorteres, må det gjøres eksplisitt. Bokas stil er en eksplisitt finn-beste-løkke, som kommer i kap. 6.3.

Containeren skal ikke lage objektene; det gjør den som kaller. Da kan det samme objektet legges i to samlinger, og den som kaller, beholder en referanse til det.

Begge former forekommer i settene, men objektvarianten er den fasiten bruker, og den er mer fleksibel.

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

Ja: ordbok. Nei: liste.

Er du usikker, velg liste og skriv en finn-metode med en løkke. Det gir full uttelling, og det er lettere å skrive riktig når klokka går. Ordboka er en optimalisering, ikke et krav.

Det er helt vanlig i Oppgave 4: én handling i domenet berører to objekter. Begge delene hører hjemme i else-grenen, slik at et avvist forsøk ikke registrerer noe.

Kjenn den igjen i oppgaveteksten på ordet «samtidig» eller på to setninger som hører sammen: «en sal kan melde på et medlem, og påmeldingen skal registrere et besøk».

Skriv alltid en test som treffer både det som finnes og det som ikke finnes:
print(b.finn("Sult")) og print(b.finn("Naboer")).

På eksamen er det ingen som kjører koden din, men vanen er verdt å ha likevel:
den tvinger deg til å tenke gjennom hva som skjer når søket mislykkes.

Det er nettopp den situasjonen if navn in ...-sjekken finnes for.

Hver container-klasse i Oppgave 4 består av de samme fire bitene:

1. samlingen i konstruktøren,
2. en legg_til,
3. et oppslag med sjekk (hvis ordbok),
4. én eller flere metoder som delegerer.

Kan du de fire, kan du skrive halve Oppgave 4 uten å tenke — og bruke tiden på algoritme-metoden i stedet, som er der de vanskelige poengene ligger.