新人エンジニアが押さえるべき設計の基本：SOLID原則の全体像と各原則の役割
山崎講師こんにちは。ゆうせいです。
プログラミングにおける設計には、変更に強く、理解しやすいコードを書くための共通の指針があります。その代表的なものが、5つの原則の頭文字をとったSOLID原則です。ソフトウェアの規模が大きくなっても、土台がしっかりしていれば崩れることはありません。今回は、この設計の土台となる5つの考え方を解説します。
SOLID原則とは何か
SOLID原則は、オブジェクト指向プログラミングにおいて、保守性や拡張性を高めるために考案された5つの設計原則です。これらを守ることで、一部の修正が思わぬ場所に影響を及ぼす「バグの連鎖」を防ぐことができます。
各原則の名称は以下の通りです。
- 単一責任の原則（SRP）
- 開放閉鎖の原則（OCP）
- リスコフの置換原則（LSP）
- インターフェース分離の原則（ISP）
- 依存性逆転の原則（DIP）
それぞれの内容を、具体的な比喩を交えて確認していきましょう。
1. 単一責任の原則（SRP）
単一責任の原則とは、1つのクラスやモジュールは、たった1つの責任だけを持つべきであるという考え方です。
高校の部活動に例えると、料理部の部長が「練習メニューの作成」と「会計」と「他校との試合交渉」のすべてを一人で抱え込んでいる状態は、この原則に反しています。もし会計のルールが変わっただけで、練習メニューの作成まで滞ってしまう可能性があるからです。
役割を「技術指導」「会計」「渉外」と明確に分けることで、特定の変更が他の業務に影響を与えないようにします。プログラムにおいても、1つのクラスが担う役割を絞ることで、修正時の影響範囲を最小限に抑えられます。
2. 開放閉鎖の原則（OCP）
開放閉鎖の原則は、ソフトウェアの構成要素は拡張に対して開いていなければならず、修正に対して閉じていなければならないという原則です。
これをスマートフォンの機能拡張に例えてみましょう。新しいアプリを追加したいとき、スマートフォンのOS（基盤）そのものを改造してコードを書き換える必要はありません。OS側が「アプリを追加できる仕組み」を公開しているため、既存の仕組みを壊さずに新しい機能を追加できます。
既存のコードには手を加えず、新しいコードを追加するだけで機能が増やせる状態が、この原則の理想です。
3. リスコフの置換原則（LSP）
リスコフの置換原則は、親クラスのオブジェクトを子クラスのオブジェクトで置き換えても、プログラムが正しく動作しなければならないというルールです。
例えば、「鳥」という親クラスに「空を飛ぶ」という機能があるとします。ここに「ペンギン」という子クラスを作った場合、ペンギンは鳥の一種ですが空を飛べないため、親クラスの代わりとして使うとプログラムに矛盾が生じます。
この場合、無理に継承関係を作るのではなく、共通の性質を正しく定義し直す必要があります。代わりを務めても違和感がない関係性を保つことが重要です。
4. インターフェース分離の原則（ISP）
インターフェース分離の原則は、利用しない機能への依存を強制してはならないという考え方です。
多機能な事務用複合機を想像してください。「印刷」「スキャン」「FAX」のすべてのボタンが1つの巨大なパネルにまとまっており、印刷機能だけを使いたい人にも、複雑なFAXの設定を理解させなければならない状態は不便です。
利用者の目的に合わせて、「印刷用パネル」「FAX用パネル」と操作インターフェースを小分けにすることで、利用者は自分が必要な機能だけを意識すれば済むようになります。
5. 依存性逆転の原則（DIP）
依存性逆転の原則は、上位のモジュールが下位のモジュールに依存するのではなく、両者が「抽象（ルール）」に依存すべきであるという原則です。
壁のコンセントと家電製品の関係が分かりやすい例です。テレビや冷蔵庫といった家電（具体的な製品）は、壁の中の配線（具体的な実装）に直接つながっているわけではありません。「コンセントの形状」という共通の規格（抽象的なルール）に従っています。
この規格があるおかげで、壁の中の配線がどうなっていても、コンセントさえ合えばどんな家電でも差し替えて使うことができます。プログラムも同様に、具体的な処理内容ではなく、共通のルールに依存させることで、部品の交換が容易になります。
SOLID原則のメリットとデメリット
これらの原則を適用することには、事実として以下の側面があります。
メリット
- 変更箇所の特定が容易になり、修正によるバグの発生を抑制できる。
- コードの役割が明確になるため、他のエンジニアが内容を理解しやすくなる。
- 部品ごとの独立性が高まり、テストコードの作成がスムーズになる。
デメリット
- 原則を忠実に守ろうとすると、クラスやファイルの数が増加する傾向にある。
- 抽象化を行うための設計工程に、一定の学習コストと時間が必要になる。
- 小規模な使い捨てのツールなどでは、過剰な設計となり開発効率を落とす場合がある。
まとめ
SOLID原則は、単にルールを守ること自体が目的ではなく、長期的にメンテナンスしやすいソフトウェアを作るための手段です。すべての原則を完璧に適用しようとするのではなく、まずは自分の書いているコードが「1つの役割に集中しているか（SRP）」といった点から意識してみてください。
学習のステップとしては、以下の順序で取り組むことを推奨します。
- 自分が書いたクラスの役割を言葉で説明し、1つに絞られているか確認する。
- インターフェースや抽象クラスを使い、具体的な処理を切り離す練習を行う。
- 既存のオープンソースライブラリの設計を読み、どのように原則が適用されているかを分析する。
論理的な設計スキルを磨くことで、チーム開発において信頼されるエンジニアへの道が開かれます。
セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。
投稿者プロフィール
- 代表取締役
-
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。
学生時代は趣味と実益を兼ねてリゾートバイトにいそしむ。長野県白馬村に始まり、志賀高原でのスキーインストラクター、沖縄石垣島、北海道トマム。高じてオーストラリアのゴールドコーストでツアーガイドなど。現在は野菜作りにはまっている。
