日々の破片

_ テストファースト

頭の中でインターフェイスを考えるってのは、まさにTDDの効果の1つだったな、と再確認。

確かに、再利用不要なインターフェイスであれば、最初からクラスとして設計するけど、その場合であっても考えるのはインターフェイスでした。

_ もうちょっと考えてみた。

特徴：

Saisseさんのモデルは、グーチョキパーがコード上で可視化されるから確かに読みやすそう。

tpircsさんのモデルは、Saisseさんのモデルに加えて、Playerがあるからコンピュータの手の選択方法の変更に強そうだし、またJudgementの導入効果は大きそう。

僕のは、（現実的には4次元=3⁴が限度だろうけど）プレイヤー（や手――この場合チャートは相当できかくなるが）の追加に強いはず――このへんは通信制御プログラミングからの影響が強いから、相当コンサバなアプローチではないかな。って言うか、vtbl経由で呼べるかってんだい、みたいなもので、おそらくSaisseさんの言っていることが一般的には正しいと思います（が、自分の好みを優先しているから「x. 勝敗判定がわかりにくい」という添削結果は作らない）。

同じプログラムでも、どうモデル化するかで違うものになるところがおもしろい。

おもしろいんだが、これをもし問題だと考えるのであれば、将来を見越したユースケース分析ってのを重視するか（分析重視）、後からいかようにでも組み合わせを変更できるようにクラスを小さく分けていくか（モデル重視と言ってもTDD的な実装時の分離のような）のどっちかになるんだろうか。すると、最初の時点でtpircsさんのかな。

_ アンテナ

っていうか、書いて、コミット、読んで修正、コミットというスタイルだと書きかけのを読まれるんで、あまり嬉しくないが、これもTDDならではということだな。というか、公開サーバーでそれをやるのが間違い（というか、赤や黄色をコミットしてはいかんだろう）。が、ここは「おいらの家」だからあまり気にしない。家はハウスで家庭はホーム、すると「おいらの家庭」ですか？

_ さらに追加（勝敗判定の箇所）

昨日のを読むと、添削結果の実装継承のところで、Resultからの継承でexecuteメソッドの意味を2重化しているのがわかる（かたほうはどの手が入力されたかの状態表示で、もう一方が勝敗の結果表示とか）。

ここを、ResultをJudgementとして、この中で元のResuslt#executeの表示と、勝敗表の検索（元のGcp#execucteで実行しているやつ）を行うのが役割分担としては正しいのかなと思います。そうすると、win, fair, loseの各カウンターはJudgementのインスタンス変数となり、元のWinとかloseとかは結果表示とカウンター設定用のJudgementのインナークラスとなる。

そんな感じですかね。