オブジェクト指向設計の原則 - クラス設計の原則

少し勉強したんで、メモ。

たぶん、今後更新していきます。

クラスを変更する理由は1つ以上存在してはならない。

クラスが持つ責任は１つってこと。
まあ、当たり前のことだけど、難しいよね。

Proxyパターン, Facadeパターン, Iteratorパターンをつかうと、
うまく責任を分割できる。

ソフトウェアの構成要素は、拡張に対して開いていて、修正に対して閉じていなければならない。

開いているとは、モジュールの振る舞いを拡張できるっていうことで、
閉じているとは、モジュールの振る舞いを変更しても、
そのモジュールを利用しているソースを変更する必要もないし、
バイナリも再コンパイルする必要ないってこと。

StrategyパターンやTemplate Methodパターンを使うといい。

派生型はその基本型と置換可能でなければならない。

派生クラスが基本クラスとして使われるときに、常に正常に動作することを保証しなければならない。
つまり、プログラマが派生クラスを意識して実装しなくてはならない状況はダメ。

注意したいところは、派生クラスのみが投げる例外とか、
派生クラスにおいて退化している機能。
Javaなんかだと派生クラスでUnsupportedOperationExceptionを投げるメソッドがあるけどLSP違反だね。

上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。
「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。

クラス同士の関係は、一旦、抽象クラスかインターフェースを噛ませろってこと。
DIみたいな。
でも、バランス考えないと、インターフェースだらけのソースコードになって読みづらいよね。

クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。

要は、太った(多機能な)インターフェースは変更があったときに、
その機能をつかってないクライアントにまで変更を強いてしまうことがある。
クライアントに応じて、インターフェースをきちんと分解しましょう。

それぞれの原則が互い関連している感じ。
結局一番大切なのは、オープン・クローズドの原則だね。