Van vraagdictionaries naar vraagobjecten

Het project uit hoofdstuk 3 verwerkte volledige pogingdictionaries via meerdere functies. Dat ontwerp werkte omdat elk record de sleutels gebruikte die die functies verwachtten.

Vraagdictionaries volgen dezelfde regel. Een bekende quizvraag ziet er zo uit:

question = {
    "prompt": "What does len('cat') return?",
    "answer": "3",
}

Dit ontwerp werkt. Dictionaries zijn geen fout en een klasse is niet automatisch beter. In dit hoofdstuk onderzoeken we wat er gebeurt wanneer een groeiend programma ervan afhangt dat elke vraagdictionary precies dezelfde vorm heeft.

Vergelijk deze vragen:

questions = [
    {
        "prompt": "What does len('cat') return?",
        "answer": "3",
    },
    {
        "text": "Which keyword starts a function?",
        "answer": "def",
    },
]

De tweede dictionary gebruikt text waar het programma prompt verwacht. Python kan die dictionary zonder bezwaar maken. Het probleem verschijnt later, wanneer een ander deel van het programma de ontbrekende sleutel probeert te gebruiken.

Het gedrag staat ergens anders

Een functie kan een antwoord controleren:

def is_correct(question, response):
    return response == question["answer"]

De vraaggegevens staan op één plek, terwijl de regel om met die gegevens te werken ergens anders staat. Naarmate het programma groeit, kan een wijziging aan de dictionary ook wijzigingen vereisen in elke functie die de sleutels gebruikt.

Dat is de ontwerpdruk die we aanpakken. We willen een betrouwbaar soort waarde dat:

• altijd één quizvraag voorstelt;

• de informatie bevat die een vraag nodig heeft;

• de bewerkingen biedt die bij een vraag horen.

De volgende les introduceert de manier waarop Python zo’n waarde definieert. Controleer eerst of het probleem duidelijk is.

Probeer de fout

De editor bevat twee vraagdictionaries en een functie die hun vraagteksten toont. Voer die uit, lees de laatste regel van de fout en herstel daarna de afwijkende sleutel.

Herstel voorlopig alleen de afwijkende sleutel. Laat het bestaande ontwerp eerst weer werken. Een nuttige abstractie moet een probleem oplossen dat je begrijpt, geen probleem verbergen dat je nog niet hebt onderzocht.