Rozdział 17 · Model i zasady
Model stanu gry
Tkinter pokazuje grę i przekazuje dane wejściowe użytkownika. STAN GRY to osobna rzecz.
Co w ogóle powinna pamiętać program?
Widgety – NIE jest kanonicznym stanem gry
Przyciski na ekranie WYŚWIETLAJĄ stan – nie są stanem – jeśli najechanie myszką tymczasowo narysuje „X”
Prototyp: state w zmiennych globalnych
Rozdział 17.3 zastosowała dokładnie takie podejście:
prototip_globals.py
tekuschij_igrok = "X"
polya = []
igra_okonchena = False
Prototyp: najpierw sprawiamy, że stan jest widoczny
Zmienne globalne — akceptowalny wybór dla pierwszego małego prototypu: łatwo je czytać i łatwo wyjaśnić. Problem pojawia się, gdy projekt rośnie — zmienne globalne tworzą ukryte powiązania między funkcjami, które niejawnie oczekują, że ktoś inny już je zmienił we właściwej kolejności. To nie znaczy „zmienne globalne są złe”: to oznacza, że mają kompromis między prostotą a utrzymaniem, na który warto zwrócić uwagę.
Ścieżka tego rozdziału
Od zmiennych globalnych do GameState
V1 - Global (17.3)
3 oddzielne zmienne
proste, ale rosnące niekontrolowanie
V2 — słownik
{'board': [...], ...}
jeden obiekt zamiast trzech zmiennych
V3 — GameState (17.19)
@dataclass
maszynisty, czytelny, testowalny
Jeden stan — różne widoczne momenty gry
Praktyka: Symulacja stanu gry
Automatyczna kontrola – buduj i sprawdzaj słownik stan bez Tkinter