「キミキタ」に粘着

はてブで一通り目を通して「オブジェクト指向が云々」と言ってるのは僕くらいだったので反応してみる。

あと、Ｊａｖａなのにいまいちオブジェクト指向してないという意見もあった。これはどちらかというとスコアを所持するのがプレイヤーか審判かの問題のような気もする。アーキテクチャレベルで判断すべき。ダブルスの問題もあるし。

アーキテクチャとかダブルスの問題とかはよくわからないんで置いといて。
僕が書いた Player クラスってのは、審判の頭にいる(もしくはスコアブック上の)プレイヤーをモデル化しています。審判が2人のプレイヤー(の概念)を所持していて、それぞれのプレイヤーがスコア(と名前)を所持している、と。つまり審判が int を持っているか Playerオブジェクトを持っているかの違いしかない*1。
それで何が嬉しいのかというと、この後のロジックででてくる「勝っているプレイヤー・他方のプレイヤー」という抽象化がやりやすい事です。
元のコードではプレイヤーのインデックス(1か2)を得るロジックとプレイヤーの得点を得るロジック(gamesWon配列の0か1)が分かれていますが、オブジェクトにしておけばどちらのインスタンスが勝っているかを判断すれば後はそのプロパティにアクセスするだけです。
概念がそのままコードになってわかりやすい上にロジックも減ってバグが入り込みにくいと言うのが狙いです。
「それ構造体で！」っていうのはその通りでそれがクラスですね。
gamesWon[playerIndex][gamesCount] っていう別解もありますが、これは前回述べた通りです。

結局のところ「そろそろ Java で C をやるのは止めませんか?」って言いたいだけなのです。

• -

enum に関しては(僕がJavaから始めたからか)正直よくわかりません。

public void gameWon(int player)

が

enum PlayerEnum {ONE, TWO}
public void gameWon(PlayerEnum player)

になるくらいでしょうか？ 確かに安全で気持ち悪くは無いけど、この場合は数も少ないしそんなに嬉しくも無いかも。

• -

オブジェクト指向言語における列挙型の意義
http://www.aerith.net/design/enum-j.html

後で読む。

• -

「キミのコードが汚い理由」という記事に例示された「クリーンな」コードが汚い件
http://d.hatena.ne.jp/haruyutaka/20070115

コードの最適化だけじゃなくて設計の最適化も行って欲しいと思いました。Playerクラスがスコアを持ってないならオブジェクトにする意味があまりないし、new Player(2) が許容されるのはちょっと…。（Player クラスが public でなければまあいいかって感じですが。）

このあたりのことは「リファクタリング―プログラムの体質改善テクニック」の最初の方に書かれています。おすすめです。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

*1:その違いが惜しい環境で Java は使われない