👏

SOLIDの原則

1 min read

概要

  • Single Responsibility Principle:単一責任の原則
  • Open/closed principle:オープン/クロースドの原則
  • Liskov substitution principle:リスコフの置換原則
  • Interface segregation principle:インターフェース分離の原則
  • Dependency inversion principle:依存性逆転の原則

Single Responsibility Principle:単一責任の原則

クラスは1つのことだけ責任を負うべき

この原則は以下の様に複数の利用者を想定すると理解しやすい。

  • 1つの利用者の要件変更が別の利用者の既存要件を破壊する
  • 複数の利用者による要件変更により、マージ時にコンフリクトが発生する

つまり、複数の役割を持つモジュールでは複数の利用者の要件を同時に満たせなくなるケースが発生しやすい。

  • プロパティの管理とDBストレージの管理の分割
  • 社員クラスが人事と総務の役割を負うべきではない
  • 〇〇Managerの様な神クラスを産まない。

Open/closed principle:解放閉鎖の原則

ソフトウェアのエンティティは拡張に対して開かれていなければならないが、変更に対しては閉じていなければならない

言い換えると、「既存コードへの修正は((最小限しか)必要なく、機能拡張できるべき」だと思う。

これを実現するには、機能拡張を新しい型で追加していくのが例としてよく挙げられている。なので拡張が想定される箇所をポリモーフィックな呼び出しにしておく必要がある。

Liskov substitution principle:リスコフの置換原則

派生型(子クラス)は基本型(親クラス)と代用可能でなければならない。

子クラスは親クラスと同じ動作をしなくてはならないということ。
すごく簡単に言うなら、I/F(引数、戻り値)の型が一致していれば良い。

Interface segregation principle:インターフェース分離の原則

利用者にとって不要なメソッドへの依存を強制してはなならない。

Dependency inversion principle:依存性逆転の原則

具体ではなく、抽象に依存しなければならない。

変更されやすい実装には依存させず、安定した抽象に依存させる。
具体的にはポリモーフィックな実装にし、その際に実装クラスではなくインターフェースに依存させること。

GitHubで編集を提案

Discussion

ログインするとコメントできます