memo "クラス設計の指針"

1.プログラムが対象とする必要のある自然のカテゴリが存在するときは、プログラムの中にそのカテゴリに対応するクラスが存在すべきである。(explicit-representation pronciple)

2.メンバ変数およびメンバ関数をクラス定義間に分配して、同一のプログラムコードの重複がないことを確実にするべきである。さもないと重複したコピーが使われて、不必要な差異をもたらすことになる。(no-duplication principle)

3.互いに関連するプログラム要素がディスプレイ上の互いに接近した位置に表示されていると、それらのプログラム要素が一体になって動作する様子が一目でわかる。一方、関連するプログラム要素が同一画面上には表示されないとしたら、何が起きているのかを理解するのに余計な困難を背負うことになる。(local-view principle)

4.プログラムは、それが実行可能な場合は計算によって頻繁に必要とされる解を求めるのではなく、それを捜し出すべきである。ex)必要なのは半径なのか、直径なのか・・・ (look-it-up principle)

5.一般的には、自分以外のプログラマによって使用されることを前提にクラスを定義するとき、それらのクラスは自分以外のプログラマが書いた関数によってアクセスされると予測する数よりもはるかに多くのメンバ変数とメンバ関数を含むものである。自分の書いたクラスへのアクセスを公開インタフェースにあるメンバ変数とメンバ関数に制限することによって、取り除こうとするメンバ変数や動作を変更しようとするメンバ関数に他のプログラマが依存しているかどうかを気にすることがなく、公開インタフェース外のメンバ変数やメンバ関数を変更したり改良したりすることが可能になる。(need-to-know principle)抽象化原理

6.普通は、複雑なプログラム要素を持つプログラムは書いたりデバッグしたり改良したり保守したりすることが困難なものである。その結果、クラス定義が簡単に理解するには複雑--20行程度を越えるときはまちがいなく--二なり始めるときは、そのクラスに属していることを表す二重コロン記号の助けを借りてメンバ関数定義をクラス定義の外部へ移すことを考える方が良い。同様に、どのような関数定義であっても、それが簡単に理解するには複雑すぎるときは、独立にデバッグと保守賀できるような複数の小さな関数に分割することを考える方がよい。(keep-it-simple principle)

付録))
クラスを実装する段階になったら、クラスの実装のみならずプログラミング一般に適用できる次の原理をまもるとよい。
::モジュール化原理::
一般に大きなプログラムはその各々が独自のファイルとなるような、複数の論理的に閉じているモジュールに分割すべきである。このアプローチの最初のステップは、クラス定義と普通の関数定義とを分けることである。次のステップは、クラス定義を関係するもの同士に分けることである。