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?

state : GameStateboard = ['', '', '', '', '', '', '', '', '']current_player = 'X'game_over = Falsewinner = Nonewinning_line = Nonescore_x = 0score_o = 0draws = 0
To dane — ani jeden przycisk Tkinter tutaj.
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

Puste pole i status Ruch gracza: X
Rzeczywisty stan kanonicznej aplikacji: początek rundy, ruch X.
Po pierwszej turze status X zmienił się na Turę Gracza: O
Rzeczywisty stan tej samej aplikacji po poprawnym ruchu X: modelu zmienił current_player na O.
Pięć oznaczeń X i O na planszy, partia trwa dalej
Rzeczywisty stan pośredni w aplikacji kanonicznej: board zapisuje status_var pokazuje aktualnego gracza.
Praktyka: Symulacja stanu gry
Automatyczna kontrola – buduj i sprawdzaj słownik stan bez Tkinter
Otwórz praktykę →