【保存版】SOLID原則を完全理解する：現場で役立つ実例とメリット、応用まで徹底解説

pgse

6日前

SOLID原則とは？現場で使える“保守しやすいコード”の基礎

プログラマーやSEとして長く開発に携わっていると、後から触れなくなるコードや、変更を入れるたびにバグが増えるコードに悩まされることがあると思います。私自身、若手の頃は「動けばOK」と勢いで実装し、後で自分の書いたコードに苦しめられた経験が何度もあります。

その悪循環を断ち切ってくれた概念が SOLID原則 でした。
SOLIDとは、オブジェクト指向設計の5つの原則の頭文字を並べたものです。

これらは難しそうに見えますが、現場で使ってみると「なぜもっと早く知っておかなかったのか…！」と思うほど効果があります。

ここからは、それぞれの原則をわかりやすく説明しつつ、実際の体験談とともに紹介します。

「このクラス、なんかいろいろ詰まっているな…」という経験はありませんか？

単一責任の原則は、
“クラスやメソッドは1つの責任だけを持つべき”
という考え方です。

新卒の頃、ログ出力・バリデーション・DB処理を1クラスに全部詰め込んだ結果、少し仕様が変わるだけで全体が壊れる“爆弾クラス”を作ってしまいました。
単一責任に分割してからは、変更の影響範囲が非常に小さくなり、レビューも通りやすくなりました。

開放閉鎖の原則とは、
“機能追加の変更には開かれているが、既存コードの修正には閉じているべき”
というものです。

決済処理を実装していたとき、最初は「クレジットカードのみ」だったので if 文で分岐していました。しかし後から「PayPay」「Stripe」「銀行振込」が次々追加され、if 文地獄になりました。

策略を変え、決済処理を抽象クラス化して決済方式ごとにクラスを分けたところ、以降は追加時に新しいクラスを増やすだけで済みました。

リスコフの置換原則は、
“サブクラスは、親クラスと置き換えても正しく動作しなければならない”
というものです。

親クラスのメソッド仕様を無視してサブクラス側で挙動を変えたせいで、呼び出し元で想定外の動作が発生し、原因調査に1日かかったことがありました。
この原則を意識すると「継承で無茶をしない」ことが徹底され、予期しないバグを防げます。

インターフェイスに余計なメソッドを並べると、不要な実装を強制することになります。
この原則は、
“クラスにとって必要な最小限のインターフェイスだけを提供するべき”
という考え方です。

以前、大きなインターフェイスをプロジェクトで共有していたため、関係のないクラスでも不要なメソッドの空実装を書く羽目になりました。
分離したことで、インターフェイスがスッキリし、保守性が上がりました。

この原則は、
“具象クラスではなく抽象（インターフェイス）に依存させる”
というものです。

ファイル保存クラスが直接ローカルストレージのクラスに依存していたため、後で「S3にも保存したい」という要望が来たときに大修正が必要になりました。
依存性逆転の原則を取り入れ、保存先をインターフェイス化したことで、以降の拡張は非常にラクになりました。

責任が分離され、変更の影響範囲が小さくなるため、後から手を入れるのが格段に楽になります。

既存コードに手を加えずに拡張できるため、リリース前に壊してしまうリスクを大幅に下げられます。

設計意図が明確になり、コードの読みやすさが向上します。

特に依存性逆転の原則は、DI（依存性注入）コンテナと合わせると効果が倍増します。テストも容易になり、モジュールの切り替えが非常に簡単になります。

SOLID原則に沿ってコードを書くと、自然とテストが書きやすくなり、TDDの効果も最大化されます。

ドメイン層やアプリケーション層の役割をハッキリ区別するのにも有効です。

SOLID原則は「きれいなコードを書くための知識」ではなく、現場の問題を解決するための実践的なツールです。
私自身、この原則を理解してから、バグ対応や仕様変更が驚くほどスムーズになりました。

今のプロジェクトが複雑で手がつけにくいと感じている方こそ、ぜひSOLID原則を取り入れてみてください。きっと開発がラクになり、チーム全体の生産性が大きく向上します。