

中嶋悟
名前:中嶋 悟(なかじま さとる) ニックネーム:サトルン 年齢:28歳 性別:男性 職業:会社員(IT系メーカー・マーケティング部門) 通勤場所:東京都千代田区・本社オフィス 通勤時間:片道約45分(電車+徒歩) 居住地:東京都杉並区・阿佐ヶ谷の1LDKマンション 出身地:神奈川県横浜市 身長:175cm 血液型:A型 誕生日:1997年5月12日 趣味:比較記事を書くこと、カメラ散歩、ガジェット収集、カフェ巡り、映画鑑賞(特に洋画)、料理(最近はスパイスカレー作りにハマり中) 性格:分析好き・好奇心旺盛・マイペース・几帳面だけど時々おおざっぱ・物事をとことん調べたくなるタイプ 1日(平日)のタイムスケジュール 6:30 起床。まずはコーヒーを淹れながらニュースとSNSチェック 7:00 朝食(自作のオートミールorトースト)、ブログの下書きや記事ネタ整理 8:00 出勤準備 8:30 電車で通勤(この間にポッドキャストやオーディオブックでインプット) 9:15 出社。午前は資料作成やメール返信 12:00 ランチはオフィス近くの定食屋かカフェ 13:00 午後は会議やマーケティング企画立案、データ分析 18:00 退社 19:00 帰宅途中にスーパー寄って買い物 19:30 夕食&YouTubeやNetflixでリラックスタイム 21:00 ブログ執筆や写真編集、次の記事の構成作成 23:00 読書(比較記事のネタ探しも兼ねる) 23:45 就寝準備 24:00 就寝
コンポジションと継承の違いをざっくり理解する
プログラミングの世界には、部品をどう組み合わせて新しい機能を作るかを決める基本的な考え方が2つあります。それが「コンポジション」と「継承」です。これらは似ているようで目的が異なり、現場の設計に大きな差を生みます。
まず、継承はクラス同士の「is-a」関係を作る道具です。たとえば「鳥」は「動物」という大きなカテゴリに属します。このように親クラスのメソッドやフィールドを子クラスがそのまま使えるので、コードの再利用が楽です。
一方で、継承は親クラスの変更が子クラスにも影響することがあるため、後から思わぬ不具合が生じやすいという難点があります。
コンポジションはhas-a関係を表現します。別のクラスの機能を自分の部品として「持つ」形で組み込みます。部品は外から差し替え可能で、親子関係のような階層依存を作らず、挙動を柔軟に変えやすいのが特徴です。例えば車を設計するとき、エンジンやタイヤを別の部品として持つようにすることで、異なる車種でも部品を入れ替えるだけで機能を変えられます。こうした方が影響範囲が局所化し、変更に強い設計になります。
この二つの考え方を正しく使い分けるには、目的をはっきりさせることが大切です。再利用性を優先するのか、拡張性と保守性を優先するのか、それぞれのプロジェクトの要求に合わせて選ぶと良いでしょう。継承は「共通の性質を自然に共有したい場合」に向いており、コンポジションは「外部の部品を組み替えやすく、挙動を柔軟に変えたい場合」に向いています。
特に大規模なシステムや長い寿命を持つソフトウェアでは、後から機能を追加したり変更したりする時の影響範囲を小さく保つために、コンポジションを優先する設計が推奨されることが多いです。
実践での使い分けと例
実際のソフトウェア設計では、どちらを使うかを「要求の変化」に基づいて判断します。
再利用性を高めたい場合は、継承をむやみに使うのではなく、共通機能を親クラスに置くよりも、共通機能を別のクラスとして切り出しておくと後からも再利用しやすくなります。例えば、複数の車の共通機能を「乗り物」という抽象クラスに置くのではなく、エンジン、ブレーキ、ライトといった部品をそれぞれ別のクラスにして、それらを車オブジェクトが組み合わせる形にすると、部品の差し替えが容易になります。
一方、拡張性と保守性を優先したい場合は、コンポジションの力を借りると良いです。新しい機能を追加したいとき、既存の部品を置き換えたり、新しい部品を追加したりするだけで済む場合が多いです。例えばゲームキャラクターを設計する場合、歩く・走る・ジャンプするといった動作を「動作部品」として別々に作っておき、キャラクター自身はそれらを組み合わせて動作するようにします。こうすることで、同じ動作を持つ別のキャラクターにも部品を再利用でき、追加の修正箇所を最小限に抑えられます。
実践例の整理
以下の例は、現実のアプリケーションでよく出会うパターンを想定しています。
1) 継承を使うパターン: あるクラスが別のクラスの機能を“そのまま”使い、少しだけ上書きしたい場合。
2) コンポジションを使うパターン: 機能を部品化して、異なる組み合わせで新しい機能を作る場合。
3) 両方を組み合わせるパターン: 基本的な共通機能は継承で持ち、特殊な機能はコンポジションで追加することで、両方の利点を活かす設計を目指します。
表で整理するとわかりやすい
この表を見れば、どの場面でどちらを使うべきかの判断材料がつかみやすくなります。
実務では、初期段階で複雑な継承階層を作るよりも、まずはコンポジションで部品を組み合わせる設計を試みるのが、後の変更を楽にするコツです。
ただし、共通の挙動が強く結びついている場合には、継承が適しています。
私が初めてプログラミングを学んだ頃は、継承という言葉に強く惹かれました。親の機能をそのまま使えるから「楽だろう」と思っていたのです。しかし、現場の課題を解くうちに、継承だけでは柔軟性が足りず、部品を単独で差し替えることが難しい場面が多いことに気づきました。そこでコンポジションの考え方を取り入れるようになり、プログラミングがぐっと扱いやすくなった経験があります。今では、部品を組み合わせる発想が設計の核になることが多いと感じています。学ぶときには、まずは実例を見て「なぜこの選択なのか」を理解することが大切です。