メインコンテンツまでスキップ

SOLID 原則の深掘り

この連載について

SOLID 原則の定義を知っていても、実務では判断に迷う場面が残ります。このクラスは分けるべきか、まだ拡張点が見えないのにインターフェースを切るべきか、この継承は置換可能と言えるのか。定義そのものは、こうした問いに答えてくれません。

この連載は、5 原則それぞれについて次の 3 つを扱います。

  • なぜ守るのか — その原則が下げようとしているコストは何か
  • どう誤用されるか — 守りすぎたときに何が起きるか
  • いつ破っていいのか — 適用しない判断が妥当になる条件

あわせて、各原則が誰によっていつ提唱され、現在どう再評価されているかを一次ソースにあたって示します。

この連載の検証水準

出典が確認できなかった主張は書きません。原典にあたれず解説記事しか見つからなかった箇所は、二次情報であることを本文に明記します。出典のない「ベストプラクティス」「業界標準」という断定は使いません。

基礎記事との棲み分け

5 原則の定義と、違反例から改善例への書き換えは クリーンコードガイド — SOLID 原則 が扱います。まずそちらを読んでください。この連載はその内容を前提とし、繰り返しません。

クリーンコードガイド — SOLID 原則本連載
問い原則は何を言っているかその定義はどこから来て、どこで壊れるか
形式原則ごとに違反例と改善例を 1 組原典 / 動機 / 誤用 / 破ってよい条件
想定読者5 原則を初めて学ぶ人定義は知っていて、適用の判断に迷う人
分量1 記事全 7 章

章立て

#扱うこと
015 原則の出自原典にあるのはクラス設計の 4 原則とパッケージ設計の 6 原則で、SRP は含まれていません
02SRP と過剰分割「変更する理由」とは誰のことか。分割しすぎたときに何を失うか
03OCP と予測的抽象化来ると予測した拡張点が外れたときの損失。間違った抽象は重複より高い
04LSP と契約事前条件・事後条件・不変条件・履歴性質の 4 項目。型検査が見ているのはどこまでか
05ISP と構造的型付け動機は 2 つあり、片方は言語に依存します。TypeScript では引数型を絞るだけで満たせます
06DIP・DI・IoC3 つは別の概念です。依存を外から渡すだけでは逆転は起きません
07原則の衝突と限界原則同士が引っ張り合う場面の判断と、SOLID そのものへの現代的な批判

対象読者

  • SOLID の定義は知っていて、実際のコードにどこまで適用するか迷っている人
  • 「原則どおりに書いたのに読みにくくなった」という経験がある人
  • レビューで設計を指摘する側に立ち、指摘の根拠を言語化したい人

前提知識

必須度知識補足
必須クラスとインターフェースの基本クリーンコードガイド — クラスとインターフェース で確認できます
必須SOLID 5 原則の定義クリーンコードガイド — SOLID 原則 の内容を前提とします
推奨TypeScript の型の基本コード例は TypeScript です。原則自体は言語を問いません

この連載で扱わないこと

  • 5 原則の入門的な解説クリーンコードガイド — SOLID 原則 が扱います
  • デザインパターンのカタログ的な解説 — 原則の説明に必要な範囲では触れますが、パターンごとの構造や使い分けには踏み込みません
  • 特定フレームワークの内部実装 — DI コンテナの仕組みなど、フレームワーク固有の話題は扱いません

関連ガイド