TOC
はじめに
オブジェクト指向プログラミングにおける有名な原則であるSOLID原則についてまとめました。
何番煎じかわかりませんが、自分の言葉で書いてみようと思います。
SOLID原則とは
- Single Responsibility Principle 単一責任の原則
- Open / Closed Principle 開放閉鎖の法則
- Liskov Substitution Principle リスコフの置換原則
- Intarface Segmentation Principle インタフェース分離の原則
- Dependency Inversion Principle 依存性逆転の原則
単一責任の原則
クラスを変更する理由は複数存在してはならない。役割が複数ある場合、それぞれの役割が変更理由になり得る（責任＝役割＝変更する理由になる元）。
具体的にはプロパティの管理やあるクラスのデータベース管理など。
細かく分ければ良いわけではなく、クラス名が一言で添えられる程度の分割が良さそう。
開放閉鎖の法則
既存のコードに修正を加えないで済む手法。
拡張に対してオープンであり、修正に対してクローズドである。
言い換えると、振る舞い方を追加することで変更に対応することができ、その変更は既存の振舞には影響しないこと。
方法論としては、呼び出し側が抽象を操作し、派生クラスの追加により変更を行う。
リスコフの置換原則
基本クラスを使っている箇所では基本クラスの代わりに派生クラスを使っても動かなければならない。
例えばスーパークラスが吐き出さないExceptionをサブクラスが投げてはいけないなど、派生クラス固有のプログラムはNG。
派生クラスは基本クラスより引数の条件が緩くなければならない。例えば基本クラスが正の整数を受け付けるのに派生クラスが100以上の整数しか受け付けないのはNG。
派生クラスは基本クラスより返り値の条件が厳しくなければならない。
インタフェース分離の原則
クライアントに、クライアントが利用しないメソッドへの依存を矯正してはならない。
インタフェースを分離することで修正範囲が狭くなる。
インタフェースの規模が大きくならないよう、異なる意味合いのメソッドはインタフェースを分ける。
依存性逆転の原則
上位のモジュールは下位モジュールに依存してはならない、どちらも抽象に依存すべきである。
下位モジュールを使用する箇所に直接型定義として記載するのではなく、上位モジュールとして振る舞えるように記載する。
具体的には下位モジュールから抽出されたインタフェースを型として持ち下位モジュールは注入する形にする（定義自体を外に記載するDIが良さそう）。
下位モジュールが上位モジュールの中で直接使用されている状態を「下位モジュールが上位モジュールに依存している」と言う。
まとめ
言葉こそ知らなかったものの、普段気にしている点ばかりでした。ちゃんとソフトウェアに落とし込めているかは別の話だけど･･･。
普段気にしていても改めて言葉で書いてみると難しいですね。自分の言葉で説明できるようにならないとと改めて思いました。
デメテルの法則など、上記以外の法則・原則もあるようなので調べる必要ありです。
