SOLIDの5原則：読みやすいコードを書くための設計指針

ソフトウェアは「動けばいい」だけでは長続きしません。数ヶ月後に自分が書いたコードを見て途方に暮れた経験はありませんか？ Robert C. Martin（Uncle Bob）が提唱した SOLID は、そんな悩みへの処方箋です。

S — Single Responsibility Principle（単一責任の原則）

クラスが変更される理由は、ひとつだけであるべき。

「メール送信もデータ保存もバリデーションも全部やる」クラスは、どれかひとつを変えるたびに他の機能まで壊す危険があります。責任をひとつに絞ることで、変更の影響範囲を最小化できます。

O — Open/Closed Principle（開放閉鎖の原則）

拡張には開いており、修正には閉じている。

新しい機能を追加するとき、既存のコードを書き換えるのではなく、新しいクラスやモジュールを追加する形にする。既存の動いているコードに触れないことで、バグを生みにくくなります。

L — Liskov Substitution Principle（リスコフの置換原則）

サブクラスは、親クラスと置き換えても正常に動作しなければならない。

継承を使う場合、子クラスを親クラスの代わりに使っても振る舞いが崩れないようにする原則です。「Birdを継承したPenguinにflyメソッドを持たせていいのか？」という問いがこの原則の典型例です。

I — Interface Segregation Principle（インターフェース分離の原則）

使わないメソッドへの依存を、クライアントに強制しない。

巨大なインターフェースをひとつ作るより、用途に応じた小さなインターフェースに分けるほうが健全です。実装クラスが「必要のないメソッドを実装させられている」と感じたら、このサインです。

D — Dependency Inversion Principle（依存性逆転の原則）

具体的な実装ではなく、抽象（インターフェース）に依存する。

上位モジュールが下位モジュールの具体的な実装を直接参照すると、実装の変更が上位にまで波及します。間にインターフェースを挟むことで、依存の方向をコントロールできます。

まとめ

SOLIDはルールではなく指針です。すべてを完璧に守ることよりも、「このコード、変更しにくいな」と感じたときに立ち返る羅針盤として使うのが実践的です。まず S（単一責任） を意識するだけでも、コードの見通しは大きく変わります。