arch-solid

1 行の概要

健全なオブジェクト指向設計とコンポーネント設計を形作る 5 つの原則です。教条的ではなく、判断をもって適用します。各原則には固有の目的があり、過剰に適用した場合に陥るアンチパターンがあります。

このスキルを使う場面

• 構造／責任／結合が懸念されるコードレビュー。
• コンポーネント設計の議論：クラスを 1 つにするか 2 つにするか、インターフェースを分割するか。
• オンボーディング：多くの GoF パターンの根底にある原則を説明する場合。
• 依存関係の方向が重要となるアーキテクチャの議論（DIP はヘキサゴナルアーキテクチャの基盤です）。

このスキルを使わない場面

• 個々のコードの問題に対する具体的な修正 → パターン別のスキル（gof-*、ddd-anti-patterns）のほうが具体的です。
• チェックリストとしての教条的な適用（「SOLID の原則に違反していないか？」）— そうして SOLID はアンチパターンになります。各原則は 方向性 であり、二者択一の基準ではありません。

主な内容

S — 単一責任の原則。「クラスが変更される理由は 1 つであるべきです。」Uncle Bob による説明では、「責任 = 変更理由」であり、「責任 = タスク」ではありません。この原則が重視するのは 変更の軸 です。互いに関係のない理由で、異なる関係者が同じクラスを変更する必要があってはなりません。過剰に適用すると、メソッドごとにクラスを作り、ファイルがあちこちに増え、メリットのない間接化が生じます。

**O — オープン・クローズドの原則。**拡張に対して開き、変更に対して閉じます。既存のテスト済みコードを変更せずに、新しいコード（サブクラス、ストラテジー、プラグイン）を追加して新しい振る舞いを実現します。変化する軸を抽象化することで実現できます（gof-strategy、gof-template-method を参照）。過剰に適用すると、「将来拡張が必要になるかもしれない」という理由で、あらゆるクラスが abstract になります。これは時期尚早な柔軟性です。

**L — リスコフの置換原則。**サブタイプは、呼び出し側を壊すことなく基底型と置き換え可能でなければなりません。Square が Rectangle を継承し、setWidth(w); setHeight(h) という前提を壊すなら、両方の型が幅と高さを持っていても、その継承は誤りです。「〜である」という関係を実際の振る舞い上のサブタイプではないものにまで当てはめることで、しばしば違反されます。

**I — インターフェース分離の原則。**クライアントに、使わないメソッドへの依存を強制してはなりません。すべての実装者に関心のないメソッドの処理を強いる肥大化したインターフェース 1 つよりも、焦点を絞った小さなインターフェースを複数用意するほうが適しています。過剰に適用すると、メソッドごとにインターフェースを作り、メリットのない負担が生じます。

**D — 依存性逆転の原則。**上位モジュールは下位モジュールに依存せず、両者が抽象に依存します。抽象は詳細に依存せず、詳細が抽象に依存します。これはヘキサゴナルアーキテクチャ（arch-hexagonal）の基礎となる考え方です。インターフェースはドメインが所有し、インフラストラクチャがそれを実装します。

SOLID の誤用。

• 方向性ではなく、合否の二者択一の基準として使う。
• 過剰な抽象化の正当化に使う（「実装を切り替える可能性があるので、ここにインターフェースが必要です」— 時期尚早です）。
• 唯一の評価基準として使う。コードは SOLID を満たしていても、読みにくい、遅い、あるいは間違っている可能性があります。
• 採用の判断基準として使う。「SOLID を知っていますか」という質問では用語の確認にとどまり、原則を役立てるために必要な判断力が見落とされます。

判断のヒューリスティクス

• SOLID は、結合度、凝集度、変更について話すための語彙です。各原則は デフォルト であり、ルールではありません。対象となるコードについて判断したうえで適用してください。
• アーキテクチャ規模（ヘキサゴナルアーキテクチャ、クリーンアーキテクチャ）では、DIP が最も大きな影響を与えます。それ以外の原則はクラス／モジュール規模で働きます。
• LSP 違反はバグです（置き換えたサブタイプが呼び出し側を壊します）。ほかの SOLID 違反は設計上の懸念事項です。緊急性は低いものの、修正コストが低ければ直す価値があります。
• SOLID のためだけにインターフェースを導入しないでください。間接化のコストは現実のものです。2 つ目の実装が現れるまで（または本当に差し迫るまで）待ってください。

アンチパターン

• SOLID のための SOLID。 「SOLID を満たす」ためだけに抽象化を追加したり、クラスを分割したり、インターフェースを導入したりすること。コードの実際の動作は変わりません。パターンの名前ばかりで、中身がありません。
• 1 クラス 1 メソッド。 クラスを過剰に分割し、コードベースを小さな間接参照だらけの迷路にしてしまうこと。有用性を超えて SRP を誇張しています。
• 何にでもインターフェース。 実装が 1 つしかないのに、すべてのクラスをインターフェースの背後に置くこと。ISP の過剰な適用です。
• コード再利用のための継承。 メソッドの 30% を再利用するために基底クラスをサブクラス化し、サブクラスが基底クラスと真に同じ振る舞いをしないために LSP を破ること。
• チェックリストとしての SOLID。 「この PR は SOLID に違反しているか？」と問うだけでは、その違反が重要かどうかを見落とします。重要な違反もあれば、そうでないものも多くあります。

関連項目

• arch-hexagonal — DIP をアーキテクチャ規模で適用します。
• arch-layered — SRP をレイヤー規模で適用します（各レイヤーが 1 つの責務を担います）。
• gof-strategy、gof-template-method — 特定のパターンを通じて OCP を実現します。
• gof-review — SOLID 違反は、gof-review におけるパターンの誤用に関する問題として表面化することがよくあります。

参考資料

• Robert C. Martin 著、Clean Architecture（Pearson、2017 年）— 第 7～11 章で SOLID を扱っています。
• Robert C. Martin 著、Agile Software Development, Principles, Patterns, and Practices（2002 年）— SOLID を初期に扱った書籍です。
• これらの原則については幅広く論じられています。Uncle Bob の解釈は標準的ですが、有効な解釈はそれだけではありません。