Als developer, wil ik de speler, alle vijanden en de score in één Game-object bewaren dat ik in één keer aan de engine meegeef, zodat mijn spel niet meer op losse globals draait en de hele spelstaat overal makkelijk is door te geven.
Er is maar één spel — waarom dan een class? Kijk eerst naar wat je nu hebt: player_x,
score, enemies en running als losse globale variabelen die
overal doorheen zwerven. Precies het scope-probleem uit sprint 5.
Stel je bouwt een script dat een server monitort. Je krijgt een handvol variabelen die allemaal over diezelfde server gaan, maar los van elkaar bestaan:
connection = Connection()
cpu_usage = 0
is_online = False
memory_usage = 0
# ... tientallen regels verder, in een functie ...
def check_status():
global is_online # anders werkt het niet — scope-gedoe
connection.ping()
is_online = TrueDeze vier horen bij elkaar — het zijn eigenschappen van dezelfde server — maar niets in de code zegt
dat. Ze zwerven als losse globals rond. Wil een functie er één aanpassen, dan heb je global
nodig en loop je precies tegen het scope-probleem van sprint 5 aan.
ServerMonitor-object vervangt
die vier zwevende globals door één samenhangend geheel.
Klik tussen de twee weergaven. Links zweven de globals los rond je script; rechts zitten dezelfde gegevens gebundeld in één object.
Er staan losse globale variabelen klaar: player_x = 220, score = 0
en running = True. Voel hoe los ze zijn — er is niets dat ze samenbindt.
player_x en score — twee losse variabelen.game — probeer "het hele spel" op te vragen. Wat gebeurt er?score = 10 — pas een global aan.player_x = 120Schrijf een klein game-script met losse globals. Je gaat de losse globals in kaart brengen — de voorbereiding op het bundelen tot een object.
player_x, score, enemies en running).add_score die score aanpast, en gebruik daarbij
global.global) je hier
terugziet, en welke vier gegevens bij elkaar in één object zouden horen.Acceptatiecriteria
global.