クラス設計と原則

0, 原則で設計レビュー

・クラス設計した時は、原則を元にレビューしてみるのが良い

1, 単一責任原則

・あるクラスを変更する理由は二つ以上あってはいけない

　→Aに対する仕様変更があり時と、Bに対する仕様変更がある時、どちらでも修正する必要があるクラスは、仕事しすぎなクラスである

　→仕様変更を考慮しないけばこの原則はクリアできない

1, 解放閉鎖原則

・拡張に対して開いている

　→拡張をする時に他のクラスに影響がないようにする

・修正に対して閉じている

　→内部を修正した時にそのクラスに依存しているクラスに影響がないようにしなければならない

バリエーションの追加時に、他のクラスを修正せずに追加できるように考慮し設計をする

1, 凝集度と結合度

凝集度は高く

・関連するものは一つにまとめる

・一個仕様変更でいろんなクラスに影響が出るのは凝集度が低い証拠

結合度は低く

・片方の変更がなるべくもう片方に影響を与えないように与えないようにする

2, YAGNIの原則("You ain't gonna need it")

必要になるまで機能の実装はしない。シンプルに構成するべきであり、冗長にするな。

3, 変化しやすいところはどこか見極めろ

見極めれたなら、設計で弱点を克服

できないのであれば、シンプルに構築しとけ