# GUIポリシー

画面の組み立て、状態の置き場所、表示部品から処理担当へ操作を渡す経路、現在状態による判断を確認する。

## 判定基準

| 基準 | 判定 |
|------|------|
| Rootから画面とその部品をたどれ、どの画面や領域が各操作を処理し、関係する状態を管理するか分かる | OK |
| 複数部品が同じ対象の識別子を別々に持ち、表示や操作の対象がずれる | REJECT |
| 部品内だけで使う入力値や開閉状態を、その部品が持つ | OK |
| 表示部品が値を表示し、操作の意図を上位へ通知する | OK |
| 表示部品が特定画面のAPIを呼び、処理後の遷移や結果まで決める | REJECT |
| Mediatorが現在状態と対象を確認し、操作の受理または拒否、処理、次の状態、表示内容、操作可否、表示対象と処理対象の整合を裁定する | OK |
| 操作の可否を左右する状態を確認せず、受け付けられない操作やその処理を実行する | REJECT |
| 受理した操作の処理結果を次の状態や結果表示へ反映しない | REJECT |
| 部品が担当しない操作だけを上位へ順に渡す | OK |
| 処理済みまたは拒否した操作を上位がもう一度実行する | REJECT |
| 確認への回答を待たず、判断の前提となる対象・入力・保存状態を変える操作を実行する | REJECT |
| 確認待ちで、確認と取消の操作を受理し、それぞれの結果を状態へ反映する | OK |
| 仕様が許可または必要とする、確認対象に影響しない独立した操作まで確認待ちの間一律に停止する | REJECT |
| クリック、キーボード、フォームなどの入口が同じ状態判断を通らず、処理中に同じ処理や競合する操作を再送信できる | REJECT |
| 処理中に同じ処理の重複実行や競合する操作は止め、影響しない独立した操作は仕様に応じて続けられる | OK |

## 例

```text
NG: 共通の表示部品が、操作を受けると特定APIを呼び、
    処理後のURLまで決める
    → 別の画面で使うたび、特定の通信と遷移を受け入れることになる

OK: 独立した各操作領域が、自分の入力と処理状態を管理して操作を判断する。
    表示部品はその領域へ意図を知らせ、共通の説明画面を開く操作は親へ知らせる。

NG: 入力の破棄を確認している間に、別の入口からその入力の保存を始める
    → 確認の前提だった未保存の内容が変わる

OK: Mediatorが確認待ちの状態を見て保存を拒否し、確認への回答を待つ
```