コンポジション
英語表記: Composition
概要
コンポジションとは、プログラミングにおいて、より大きな機能や構造を構築するために、複数の小さな要素やオブジェクトを組み合わせる設計手法のことです。これは、複雑なシステムを単純な部品の集まりとして捉えることで、再利用性や柔軟性を高めることを目的としています。特に、プログラミングパラダイム（命令型, 関数型, オブジェクト指向） の中では、特定のパラダイムに限定されないマルチパラダイム的なアプローチとして位置づけられ、システム設計の良し悪しを決定する重要な実践パターンの一つとされています。
この手法は、部品となる要素が独立性を保ちながら、全体として協調して動作する関係を構築するため、システムの変更や拡張が容易になるという大きなメリットがあります。
詳細解説
コンポジションは、単に要素を寄せ集めることではなく、それらの要素間に明確な「所有関係」や「利用関係」を築くことを指します。
目的と背景
この実践パターンが重要視されるようになった背景には、従来のオブジェクト指向における「継承（Inheritance）」が持つ制約や問題点があります。継承は強力な再利用の仕組みですが、一度継承関係を結ぶと、親クラスと子クラスが強く結びついてしまい（密結合）、親クラスの変更が予期せぬ形で子クラスに影響を与えるリスクがありました。これは「ダイヤモンド問題」や「脆い基底クラス問題」などとして知られています。
コンポジションの主要な目的は、この密結合を避け、「疎結合（Low Coupling）」と「高凝集（High Cohesion）」を実現することにあります。この目的は、どのプログラミングパラダイムにおいても共通する、質の高いソフトウェア設計の基本原則です。
オブジェクト指向におけるコンポジション
オブジェクト指向プログラミング（OOP）の文脈では、コンポジションは「オブジェクトを部品として内部に保持する」関係を意味し、「Has-A（〜を持っている）」関係と呼ばれます。
例えば、「自動車クラス」を設計する場合を考えてみましょう。もし「エンジン」や「タイヤ」を継承で表現しようとすると、「自動車はエンジンである」という不自然な関係になってしまいます。しかし、コンポジションを使えば、「自動車はエンジンを持っている」「自動車はタイヤを持っている」という自然な関係で設計できます。
この方法を採用することで、自動車が別の種類のエンジンに交換されたり、タイヤの種類が変わったりしても、自動車クラス全体を修正することなく、内部の部品オブジェクトを差し替えるだけで対応できるようになります。これは、OOPにおける柔軟な設計を実現する実践パターンの代表格です。
関数型プログラミングにおけるコンポジション（関数合成）
コンポジションの概念は、関数型プログラミング（FP）の分野でも非常に重要です。FPの文脈では、「関数合成（Function Composition）」として知られています。
関数合成とは、小さな純粋関数（副作用を持たない関数）を組み合わせて、より複雑な処理を行う新しい関数を作り出す手法です。例えば、f(x)という関数とg(x)という関数があるとき、これらを合成してh(x) = f(g(x))という新しい関数を定義します。データがまるで工場内のベルトコンベアのように、一つひとつの関数を順番に通過していくイメージです。
この手法は、FPが目指す「宣言的で保守性の高いコード」を実現する上で欠かせません。小さな関数が独立してテスト可能であるため、全体として組み合わせた際の信頼性も高まります。
マルチパラダイムの実践パターンとしての位置づけ
コンポジションは、OOPの「オブジェクトの組み合わせ」とFPの「関数の組み合わせ」という、異なるプログラミングパラダイムにおいて共通して見られる、構造化と再利用の根幹をなす考え方です。
このため、マルチパラダイム的な視点で見ると、コンポジションは特定の言語機能というよりは、「複雑なものを単純な部品に分解し、それらを柔軟に結合して全体を構成する」という、普遍的な設計哲学、すなわち実践パターンであると理解できます。現代のプログラミングでは、OOPとFPの要素を組み合わせることが多いため、コンポジションの理解は、質の高いソフトウェアアーキテクチャを築くための必須スキルと言えるでしょう。
具体例・活用シーン
コンポジションの概念を理解するために、具体的な例や比喩を用いて見ていきましょう。
レゴブロックの比喩
コンポジションを最もよく表す比喩は「レゴブロック」です。
継承を「プラモデル」に例えると、プラモデルは設計図通りにしか作れず、一度組み立てると部品の交換が難しいという特徴があります。特定の完成形（is-a）を目指すのがプラモデルです。
一方、コンポジションは「レゴブロック」です。
1. 独立した部品: エンジン、タイヤ、コックピットなど、一つ一つのレゴブロックの部品（オブジェクトや関数）は、それぞれが独立した機能を持っています。
2. 自由な組み合わせ: これらの部品を、設計者の意図に応じて自由に組み合わせることで、車にも船にも家にもなります。
3. 柔軟な変更: 一度組み立てた後でも、特定の部品だけを抜き取って、別の部品に交換することができます。これは、プログラムの実行中に、あるオブジェクトが持つ機能を別のオブジェクトに差し替える柔軟性（例えば、Strategyパターン）に直結します。
私たちがソフトウェアを開発する際も、特定の機能（例えば、データの保存方法、ユーザー認証のアルゴリズム）を独立した部品として設計し、主要なシステムがそれらの部品を「所有」または「利用」することで、システム全体の構造を頑丈かつ柔軟に保つことができるのです。
活用シーン：デザインパターン
コンポジションは、オブジェクト指向のデザインパターンで頻繁に利用されます。
- Strategyパターン: 処理のアルゴリズム（戦略）を独立したクラスとして定義し、それらをクライアントクラスがコンポジションによって利用します。これにより、実行時にアルゴリズムを動的に切り替えることが可能になります。
- Decoratorパターン: オブジェクトの振る舞いを動的に追加・拡張するために、既存のオブジェクトを新しいオブジェクトで包み込みます。これもまた、機能の組み合わせによるコンポジションの一種です。
これらのパターンを利用することは、マルチパラダイム的な設計思考を深め、より洗練された実践パターンを適用することにつながります。コンポジションをマスターすれば、デザインパターンの理解も深まりますよ。
資格試験向けチェックポイント
IT資格試験、特に基本情報技術者試験（FE）や応用情報技術者試験（AP）では、設計原則やオブジェクト指向の基礎知識としてコンポジションが問われることがあります。
| 試験レベル | 重点的に問われるポイント |
| :— | :— |
| ITパスポート (IP) | 設計の基本原則として、「部品化」や「機能の再利用」の概念を問う選択肢に登場する可能性があります。システムを構成する要素を組み合わせる考え方だと理解していれば十分です。 |
| 基本情報技術者 (FE) | オブジェクト指向の基本設計手法として、継承（Inheritance, is-a） と コンポジション（Composition, has-a） の違いが頻出します。コンポジションが「疎結合」を実現し、「柔軟性」を高める手段であることを理解しておく必要があります。 |
| 応用情報技術者 (AP) | ソフトウェアアーキテクチャやデザインパターンの文脈で問われます。特に、コンポジションがStrategyパターンやDecoratorパターンの基盤技術であることを知っておくと有利です。また、継承の問題点（密結合、脆い基底クラス問題）を回避する実践パターンとしての役割を論述問題などで説明できると理想的です。 |
試験対策のヒント:
- 「継承よりもコンポジションを優先せよ（Prefer Composition over Inheritance）」という格言は、オブジェクト指向設計の鉄則です。この理由（疎結合の実現）を明確に説明できるようにしておきましょう。
- コンポジションは、部品を交換・差し替え可能にするため、システムの拡張性・保守性を高めます。このメリットは、試験で頻繁に問われる重要キーワードです。
- 関数型プログラミングの知識も問われる場合、関数合成がコンポジションの一種であることを知っていると、マルチパラダイム的な視点を持っていると評価されます。
関連用語
コンポジションは、ソフトウェア設計の根幹に関わる概念であるため、多くの用語と関連していますが、ここではこの文脈で特に重要な関連用語を挙げます。
- 継承 (Inheritance)：クラス間の「is-a」関係を構築する手法。コンポジションと対比して理解することが非常に重要です。
- 疎結合 (Low Coupling)：システム内の構成要素間の依存度が低い状態。コンポジションの主要な目的の一つです。
- 高凝集 (High Cohesion)：構成要素（クラスやモジュール）が、単一の明確な責任に集中している状態。
- デザインパターン (Design Pattern)：GoFのデザインパターンなど、コンポジションを具体的な形で利用する実践パターンの集まりです。
