■変更要件
リファクタリングし追加予定仕様に耐えうる設計にする

1.ミノ管理クラスの簡素化
→
　利用箇所の不要なロジック、キャストの削減
　管理情報の縮小

2.switch文を最小限にする
キーのマップ化(テキスト分離まではしない)

3.直値禁止
　どうしてもは理由を記載
　(意味の持たない定数のみだと思う)

4.TODO対応

■設計メモ
Playerクラス
　ストリーム(親クラスいったっけ？)のIFより操作を取得する
　開始制御
private関数はできる限り削る
キャストは悪の根源
→設計検討を行う

TablePanelのswitch文撲滅
　Palletクラスにて色の対応付けを管理
　引数をtypeで戻り値ColarのIF追加
全体:定数はすべてstatic finalで定義

GameThreadAI,GameThreadの統合
→まずは、差分確認
1.runの分割
　・pre,postを分離
　→構造まとまりならあり
　　まとまりないなら、ただの3分割

Minoクラス
　1フィールドに発生するのは1つ
　→ネクスト含めると2つ以上
　設置済みはブロック(描画用に種類は保持)
　中心と周囲3点の情報を保持
　回転すると3点の位置が変わる
　回転規則に則り中心は移動する
　→案1:
　　中心は可変
　　周囲3点は固定で4種類(90,180,270,360)
　　固定のため分離して保持して良い
　　ミノの種類として1つの形に4種類
　メリット:可変で管理する情報が少ない

 　→案2:
　　中心は可変
　　周囲3点は固定で1種類
　　回転状態状態(90,180,270,360)
　→案3:
　　中心は可変
　　周囲3点は可変で1種類
　　(回転操作により周囲3点が回転
　
　GameThread#run()
      ぱっと見処理のまとまりがあるように見えるが、private関数は抜き出さない
　理由:ゲームルールは固定のため
　playerとの接続部分は検討要
　→AIとの差分結果を参考にする

　GameThreadの責務多すぎ？
　　disp.playerを保持
　　管理・互いの通知
　　→通知だけなら一方通行にしたい
　　　(中間層


■責務分担(メモ)
1.キー操作→テーブル→画面描画
MyPlayer
　・キー入力の監視( KeyListener)
　・監視対象の設定(アプリのウィンドウに設定している)
　・監視対象から取得した入力をテーブルに行う操作に変換して保持
　・テーブル操作の通知IF提供
　　補足:テーブルに通知しにいかないのは入力が不定期のため。
　　対応方法は以下の2つ(もっとある？)
　　1.イベント処理関数に経由でテーブルに通知
　　-イベントをハンドルする担当が必要(ゲーム進行者が担当？)
　・ゲーム開始合図(監視対象へのキー入力)待ち
　 -テーブル操作の通知IFから、開始合図としての入力を取得する

Table
　・ブロックの2次元配列を管理
　・ネクストテーブルを保持
　・見えないブロックを内部で扱う
　・ミノの操作系処理に対しては座標をラップする
　○ミノの操作系処理
　・ミノの生成
　・ミノの設置可否判定
　　(中心と他3点)
　・ミノの設置、削除
　・ミノの移動
　・ミノの回転(SRSに基づく中心の移動も含む)
　○ライン削除　→空と削除対象の区別が必要
　・削除対象ライン設定
　・削除対象ラインの上のブロックを詰める


Display
 ・テーブルの描画
 ・ネクストの描画
 ・ゲーム開始合図待ち
 
MyGameFrame
　・Displayとしての責務をJFrameで実現。
　・プレイヤーからのキー操作を促すメッセージを画面に描画
　・ゲーム開始合図(プレイヤーからのキー操作)を待ち

2.テーブルにブロックの描画
Mino　→　Block　→　Table

Blockクラス
　ミノの形毎に種類分けをしている　→　描画時に色分け用に利用


