Cartesian School CartesianSchool
Python od zera / Rozdział 17 / Model, nie widgety
Rozdział 17 · Architektura

Od widgets-as-state do board model

Tymczasowo narysuje X na pustym przycisku. Jeśli jest to „stan”

Rozdział 17.3 przechowywała stan W przycisku TEXT

widget_kak_istochnik.py
# text przycisków — jedyne miejsce, gdzie przechowuje się „czy pole jest zajęte, czy nie”
if polya[indeks]["text"] != "":
    return

To zadziałało dla małego prototypu. Ale wyobraź sobie efekt zawisusu (Rozdział 17.23): tymczasowo wyświetla się "X" na przycisku pustym przed wykonaniem ruchu. Jeśli stan ŻYJE w Tekst przycisku — Program nie potrafi już rozróżnić "hover" od "real move".

najechanie (zapowiedź)prawdziwy klik(obrót)button['text']się zmieniło
Jeśli oba mają ten sam sygnał, jak je odróżnić?

Modeluj osobno, tylko przycisk

MODEL
board[4] = 'X'
↓
render()
↓
VIEW
buttons[4] pokazuje 'X'
Dane płyną w jednym kierunku: model → render() → widżet. Nigdy nie jest odwrotnie.
Przycisk może TYMCZASOWO wyświetlać inny model
Podczas najechania buttons[4]["text"] == "X", a board[4] == "" — i jest W PORZĄDKU, jeśli model pozostaje źródłem prawdy. Problem zaczyna się dopiero wtedy, gdy kod (np. winner check) odczytuje stan z tekstu przycisku zamiast z modelu — zobacz Debug Lab 3, sekcja 17.29.

board = lista liniach – model końcowy

board_model.py
board = ["", "", "", "", "", "", "", "", ""]
#board[4]=„X”
Praktyka: Model vs. Widget-as-State
Automatyczna kontrola – na modelu zabawki widgetu bez Tkinter pokazania, dlaczego widget-as-state psuje
Otwórz praktykę →
← Back
Wygrywaj, remisuj, terminal state