1. 崩壊の起点は“イベントハンドラの肥大化”ではない

多くの記事は「イベントハンドラにロジックを書きすぎるな」と言います。しかしそれは結果論です。

本当の問題は、GUIが単一イベントループ上で時間順にしか実行されないという制約です。

基本構造はこうです。

このモデルでは、

・すべての処理はイベント起点

・すべての副作用はUIスレッド上で発生

・実行順序は“時間”に依存

つまり、アプリケーション全体が「時間依存プログラム」になります。

規模が小さいうちは、時間依存性が目立ちません。

規模が拡大すると、時間依存が設計破綻の主因になります。

2. 状態寿命が延びた瞬間に破綻が始まる

小規模アプリの状態は短命です。

ボタン押下→ 計算→ 表示

状態はそのイベント内で完結します。

しかし中規模以上になると、状態が“生き続ける”ようになります。

例：

・ログイン情報がアプリ全体で共有

・APIレスポンスをキャッシュ

・画面間でオブジェクトを再利用

・非同期処理が完了後にUI更新

この瞬間、状態はイベント境界を越えて生存します。

状態寿命が延びると、次が発生します。

・更新順序の非決定性

・古い状態の参照

・二重更新

・破棄忘れ

ここから「たまに壊れる」バグが発生します。

3. 非同期導入が設計の弱点を露出させる

同期設計では問題が隠れています。

しかしAPI通信や重い計算を入れると、UIフリーズを避けるために

・QThread

・asyncio

・concurrent.futures

などを導入します。

すると構造はこう変わります。

ここで発生するのは時間競合です。

例：

1. ボタンA押下 → APIリクエスト送信
2. ユーザーが別画面へ移動
3. レスポンス到着
4. すでに存在しないUIへ更新処理

これがランダムクラッシュや不可解な例外の原因です。

問題は非同期そのものではありません。

「状態の所有権を定義していないこと」です。

4. GUIは“境界を強制しない”

WebアプリではHTTPが強制的な境界になります。

しかしGUIでは

が可能です。

この自由度が依存の無制限増殖を許します。

イベントハンドラから

・データベースアクセス

・API通信

・設定書き換え

・別画面更新

がすべて直接呼び出せる。

これが密結合の温床です。

5. なぜテスト不能になるのか

巨大化したPython GUIがテストできない理由は明確です。

・ロジックがUI依存

・イベント順序が前提

・副作用が暗黙的

単体テストを書くには、ロジックをUIから切り離す必要があります。

しかし既に密結合になっていると、分離コストが極めて高くなります。

この段階でリファクタリングはほぼ再設計に等しくなります。

6. 典型的な崩壊パターン

1万行前後でよく起きる兆候：

・Controllerクラスが1000行超

・グローバル変数増加

・シグナル接続が分散

・async導入後にバグ増加

・修正の影響範囲が読めない

これは偶発ではありません。

イベント駆動＋長命状態＋責務未分離という三重構造が原因です。

7. 崩壊を止めるには何を固定すべきか

必要なのはフレームワーク変更ではありません。

固定すべきは以下です。

1. 状態の所有者を明確にする
2. UIは状態を変更しない
3. 非同期処理はUI層外で完結
4. UIは“描画専用層”に限定

理想構造：

GUIが処理を持たない限り、巨大化しても破綻確率は大幅に下がります。

Python GUIが1万行を超えると壊れ始めるのは偶然ではありません。単一イベントループという時間依存実行構造の上に、長命状態と非同期処理を積み重ねることで、更新順序と所有権が曖昧になるからです。崩壊の本質はフレームワークではなく、状態寿命の無制御拡張にあります。巨大化を前提に、UIを描画層へ固定し、状態所有と時間境界を設計段階で定義できない限り、Python GUIは構造的に必ず不安定化します。