ITフリーエンジニア・ＳＥプログラマ専門の案件紹介サイト

• クラスやインスタンス、本当に「使いこなせて」いますか？
• 1. なぜ「原則」を知らないとコードが崩壊するのか
• 2. SとO：「一つのことだけやる」「追加はOK、変更はNG」
• 3. LとIとD：「親のふりをする」「細かく分ける」「抽象に頼る」
• 4. 原則は「絶対の掟」ではなく、迷ったときの「道しるべ」
• まとめ：変更に強いコードが書ければ、あなたはもう初心者じゃない

クラスやインスタンス、本当に「使いこなせて」いますか？

プログラミング学習の最初の大きな壁、「オブジェクト指向」。
参考書を読んで「たい焼きの型（クラス）と、焼き上がったたい焼き（インスタンス）」という例え話は理解できたものの、いざ実務でコードを書こうとすると手が止まってしまいませんか？

「とりあえずクラスに分けてみたけど、これで合っているのかな……」
「どこからどこまでを一つのクラスにまとめればいいのか、基準が分からない」
そんなふうに「なんとなく」オブジェクト指向を使っている状態から抜け出せない初心者エンジニアは非常に多いです。

この記事では、そんなモヤモヤをスッキリ解消し、実務で自信を持ってコードを設計できるようになるための魔法のルール、「SOLID（ソリッド）原則」について、世界一わかりやすく解説します。

1. なぜ「原則」を知らないとコードが崩壊するのか

オブジェクト指向の構文（書き方）を知っていることと、それを「正しく設計できること」は全くの別物です。
なんのルールも持たずに巨大なアプリケーションを作っていくと、どうなるでしょうか。

一つのクラスに「画面を表示する機能」「データベースに保存する機能」「計算する機能」がごちゃ混ぜになり、数百行、数千行という巨大で解読不能なモンスタークラスが誕生してしまいます。
これを「神クラス（God Class）」と呼びますが、この状態になると、一箇所を修正しただけで全く関係ない別の場所が壊れるという、地獄のようなバグの連鎖が始まります。

こういった悲劇を防ぎ、複数人で開発しても安全で変更しやすいコードを保つための先人たちの知恵、それが「SOLID原則」なのです。

2. SとO：「一つのことだけやる」「追加はOK、変更はNG」

SOLID原則は5つのルールの頭文字をとったものです。まずは前半の2つ、SとOを見てみましょう。

【S：単一責任の原則】
これは「一つのクラスは、一つの役割（責任）だけを持つべき」というルールです。
例えば、レストランで「料理も作って、接客もして、レジも打つ」という店員さんがいたら大混乱しますよね。
プログラムも同じで、「計算するだけのクラス」「表示するだけのクラス」と役割をキッチリ分けることで、バグの原因を特定しやすくなります。

【O：オープン・クローズドの原則】
「機能を追加するときは、既存のコードを書き換えずに、新しいコードを付け足すだけで済むようにしよう」という考え方です。
ゲームで新しいキャラクターを追加するとき、本体のシステムを改造しなくても、追加データ（拡張パック）を入れるだけで遊べる状態が理想ですよね。

3. LとIとD：「親のふりをする」「細かく分ける」「抽象に頼る」

残りの3つは少し専門的になりますが、考え方はとてもシンプルです。

【L：リスコフの置換原則】
「親クラスを子クラスに差し替えても、プログラムが壊れずに動くようにしよう」というルールです。
「鳥」という親クラスから「ペンギン」を作ったとき、「飛ぶ」という機能を引き継いでしまうとエラーになります。
親子関係は慎重に設計しましょう、という教えです。

【I：インターフェース分離の原則】
「使わない機能まで、無理やり持たせるのはやめよう」という原則です。
スマホに「FAX機能」がついていても誰も使いませんよね。
必要な機能だけを小さく束ねて、必要なクラスにだけ渡すのがスマートな設計です。

【D：依存性逆転の原則】
「具体的な部品に直接頼るのではなく、抽象的なルール（インターフェース）に頼ろう」という考え方です。
これによって、後から部品を別のものに交換するのが圧倒的に楽になります。

4. 原則は「絶対の掟」ではなく、迷ったときの「道しるべ」

ここまで5つの原則を紹介しましたが、一つ注意点があります。
それは、最初からこの5つを完璧に守ったコードを書こうとしすぎないことです。

ガチガチにルールを守ろうとすると、逆にクラスの数が無駄に増えすぎて、コードが複雑になってしまうこともあります（オーバーエンジニアリング）。
SOLID原則は「絶対に破ってはいけない法律」ではなく、「コードの設計で迷ったときに立ち返るべきコンパス」のようなものです。

実務では、「今回はスピード優先だから、Sの原則だけは守っておこう」といったバランス感覚が求められます。
まずは、自分が書いたコードを見直して、「このクラス、色々な仕事を持たせすぎているかも？」と気づけるようになることが第一歩です。

まとめ：変更に強いコードが書ければ、あなたはもう初心者じゃない

オブジェクト指向の真の目的は、単にコードを短くすることではありません。
「仕様変更が来たときに、泣かずに済むコード（変更に強いコード）を作ること」です。

SOLID原則を意識できるようになると、あなたの書くコードは劇的に読みやすくなり、チームメンバーからのレビューも驚くほどスムーズに通るようになります。
「なんとなく動く」から「意図を持って設計する」へ。
原則を理解したあなたは、現場で頼られる一人前のエンジニアへの階段を確実に登っています。
今日から一つでもいいので、この原則を意識してエディタに向かってみてください。