SOLIDを考える度に、どの原則がどんなものだったかで、いつも頭がこんがらがってしまう。
とっかかりとして、一目で確認するための表が欲しくて、作ってみた。
こんな人向け
- オブジェクト指向言語を使っている
- SOLIDは一通り見聞きした事がある
- SOLIDがいつもわからなくなる
SOLIDまとめ表
| この構成の場合 | このトリガーによって | この問題が発生する | 対応策 | 原則名 |
|---|---|---|---|---|
| 一つのコードを、複数のアクターが使用している | あるアクターの文脈で、コードの修正が必要になる | 異なるアクターから見ると、期待していた振る舞いでは無くなってしまう可能性がある | コードは、一つのアクターにのみ責任を負う様にする | SRP（単一責任の原則） |
| 機能の具体的な処理と呼び出しとが、分割されていない | 機能が増える（もしくは差し替えになる） | 既存コードの、直接修正（追加機能用の分岐・処理詳細等）が必要になる | 機能の追加は新規のモジュールを追加するだけで行える様に、機能の呼び出しと実装を分割する | OCP（オープン・クローズドの原則） |
| 継承やIFが使用されている | 新しく追加するサブクラス・IFの実装の振る舞いを、スーパークラスやIFと異なる様にする ※1 | 既存コードの、直接修正（異なる振る舞いを吸収する分岐など）が必要になる | サブクラスやIFの実装の振る舞いは、スーパークラスやIFそのものとしても問題が無い様にする | LSP（リスコフの置換原則） ※2 |
| 依存先のモジュールに、自分が使用しないコードが存在している | 自分が使用していないコードの修正 | 無関係な修正に対して、再コンパイルが必要になる ※3 | 依存先を、自分が使う機能のみを定義したインターフェースにする | ISP（インターフェース分離の原則） |
| 依存先が、変更されやすいモジュールになっている | 変更が発生する | 依存元の修正や再コンパイルが必要になる | 依存先を、変更されやすいモジュールではなく、インターフェースにする ※4 | DIP（依存関係逆転の原則） |
※1 静的型付け言語ならそもそも出来ない気もするけど
※2 LSPに違反するとOCPにも違反する
※3 動的型付け言語ならこの問題は発生しない。
※4 この際、処理の流れと実際の依存の方向を逆にする必要があるため、「依存関係逆転の法則」と名付けられている