自分流プログラミング格言
設計において大切なのは
- 凝集度が高いか
- 結合度が低いか
- データの整合性を維持しやすいか
- 使用法は簡潔か
- 汎用性はあるか
- 状態はバグのもと
- 副作用はバグのもと
- 二元管理はできるだけ避けたい
- オブジェクトの初期化とクリーンアップを明確に意識する
C++ といえど全てをクラスのメソッドにする必要はない。
むやみにメンバ変数にアクセスせず、引数と戻り値で受け渡した方が
汎用性・テストのしやすさが高まるものはただの関数にしよう。
ダメージ計算式や確率計算などゲームのルールに関わる関数と
シーン制御などフローに関わる関数は別ファイルにわけよう。
特にルールに関わる方はインスタンスメソッドでなく、関数（またはクラスメソッド）にした方がいいかもしれない。
メソッドに副作用があるかどうか明確にしよう。副作用があるメソッドは値を返さないように決めるというのはいい考えです（Python はそうなっているらしい）。
すでにリリースされたソースに変更を加えるときは、その変更箇所が
if 節で囲まれていないか注意しよう。その変更箇所を通る場合の挙動
の変化は把握できているだろうが、「通らない」場合はどうなるか？
その処理を途中まで進めたところでアンドゥできるか？を考えて
ロジック・データ構造を考えよう。
【重要】ファイルのinclude関係やクラスの依存関係を表す図を書こう。
関数やファイルヘッダに（Doxygen形式などの）コメントを書くことは、その関数・ファイルの目的について再考する機会を生み、結果的に設計の品質を向上させる効果をもつ。
コメントはうざいくらい書こう。
C++ の場合、コメントの量はソース全体の12%から20%程度が適切なように思う。
grep で1行だけ取り出したとき、その行がコメントアウトされているかすぐに判別できるように行コメントだけを使うというのは泥臭いけど一利あるかも。
オブジェクト指向について
自分が考えるオブジェクト指向
オブジェクトとは関連度の高いデータを集め、それらに対する操作をまとめたもの。
オブジェクトは自分が管理するデータに対する処理を引き受け、そのデータの整合性を維持する責務を負う。
→しかしこの考えに基づくと、クラスのメソッド数が肥大化する場合がある。その場合は、オブジェクト指向の原則には反するが、関連するメソッドをまとめて別クラスに分けた方がいいかもしれない（実際、世間でオブジェクト指向的と言われる設計は処理をまとめたクラスを作っている場合が多々ある）
B.Meyer「オブジェクト指向入門」14.2.7 大いなる過ち
オブジェクト指向設計の基本ルールは機能ではなく、オブジェクトの型を中心にモジュールを構築することである。... この病気の典型的な症状はexport句に１つしかルーチンが含まれていないこと、そして、設計者が”このクラスは……を実行する”という形でしかクラスの役割を説明できないことである。ルーチンと異なり、クラスは何かをするのではなく、ある型のオブジェクトに対するいくつかのサービス（特性：feature）を提供するのである。
この考えに基づくならば XXXBuilder や StringTokenizer など動詞+er形の名前を持つクラスは不適当である。しかし実際的にはクラスの肥大化を防ぐために有用。
画面にオブジェクトを表示する場合、screen.draw(object) とするのと object.draw(screen) とどちらがよいか？
画面に表示するためには object の内部情報にアクセスしなければならず、一方 screen の方は公開メソッドだけを利用すれば目的が果たせそうである。よって object.draw(screen) の方がよい。
インスタンス変数の数は10個以下が望ましい。11個以上になったらクラスの分割を考えること。
メソッドの個数は多くなっても問題がないことが多い。
大クラス主義について
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/14675
- 関連（ポインタを保持しているが所有してはいない関係）
- 格納（リストが要素を保持するような関係）
- 集約（has a。ポインタを保持。生成と破棄の責任を負うかどうかは両方ありうる）
- コンポジション（is a part of。集約でライフサイクルがいっしょ）
継承を使うか、集約を使うか迷った場合の判断基準の１つとして
- 親クラスのメソッドをオーバーライドしたいか？したくないならば集約の方がいいかも。
【中級】基礎からのオブジェクト指向 第5部 「GRASPパターン」を理解する（前編）：ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20060607/240196/
吉田誠一氏の技術コラム
http://www.aerith.net/column-j.html
