Глава 17 · Архитектура

От widgets-as-state к board model

Наведение мыши временно рисует X на пустой кнопке. Если это и есть «состояние» — игра сломана.

Раздел 17.3 хранил состояние В ТЕКСТЕ кнопки

widget_kak_istochnik.py

# text кнопки — единственное место, где хранится "занята клетка или нет"
if polya[indeks]["text"] != "":
    return

Это работало для маленького прототипа. Но представьте эффект наведения (раздел 17.23): он временно показывает «X» на пустой кнопке, ещё не сделав хода. Если состояние ЖИВЁТ в тексте кнопки — программа больше не может отличить «наведение» от «настоящего хода».

Если у обоих один и тот же сигнал — как отличить один от другого?

Модель отдельно, кнопка — только отображение

MODEL

board[4] = 'X'

↓

render()

↓

VIEW

buttons[4] показывает 'X'

Данные текут в одну сторону: модель → render() → виджет. Никогда наоборот.

Кнопка может ВРЕМЕННО показывать не то, что в модели

Во время наведения buttons[4]["text"] == "X", а board[4] == "" — и это НОРМАЛЬНО, если модель остаётся источником истины. Проблема начинается только тогда, когда код (например, проверка победителя) читает состояние из текста кнопки вместо модели — см. Debug Lab 3, раздел 17.29.

board = список строк — окончательная модель

board_model.py

board = ["", "", "", "", "", "", "", "", ""]
# board[4] = "X"  — это НАСТОЯЩИЙ ход, кнопка лишь отображает это значение

Практика: модель против виджета-как-состояния

Автоматическая проверка — на игрушечной модели виджета без Tkinter показываем, почему widget-as-state ломается

Открыть практику →

← Назад

Победа, ничья, terminal state

GameState с dataclass