オブジェクト指向設計は、クラスどうしがどのように相互作用するかに大きく依存しています。アーキテクトがシステムを設計する際、しばしばクラス図から始めます。この視覚的なブループリントは、ソフトウェア内の構造、属性、関係性を定義します。このブループリントにおいて最も重要な要素の一つが、関係性そのものです。特に、関連、集約、コンポジションの違いは、オブジェクトがライフサイクルや依存関係をどのように管理するかを決定します。これらの概念を誤解すると、システムの一部が変更されたときに予期せぬ形でオブジェクトが破綻する脆弱なコードにつながる可能性があります。
これらの3つの関係性タイプはしばしば混同されます。すべてが2つのクラスの間の「リンク」を表していますが、そのリンクの性質は大きく異なります。このガイドでは、それぞれの関係性タイプを詳細に分析します。視覚的な表現、意味論的な意味、そして実際のコード構造への変換方法を検討します。最終的には、現実世界のシナリオをクラス図にマッピングするための明確なメンタルモデルを身につけるでしょう。
1. 関連：基本的なリンク 🔗
関連は、クラス図における最も一般的な関係性の形です。2つのクラスの間の構造的リンクを表します。クラスAがクラスBに関連している場合、クラスAのオブジェクトがクラスBのオブジェクトを参照していることを意味します。これは、他の2つの関係性の基礎となるものです。
関連の主な特徴
- 方向性：関連は単方向（1本の矢印）または双方向（矢印なし、または2本の矢印）のいずれかです。単方向は、クラスAがクラスBを知っているが、クラスBがクラスAを知っているとは限らないことを意味します。
- 多重度：これは、1つのクラスのインスタンスが、別のクラスのインスタンスと何個関連するかを定義します。一般的な表記には「1」、「1..*」（1対多）、「0..1」（0個または1個）があります。
- ナビゲーション性：コードでは、これはしばしば参照またはポインタに変換されます。どちらのオブジェクトがもう一方のオブジェクトのメモリアドレスを保持するかを決定します。
- 役割名：関連は、線の両端に名前が付くことが多く、オブジェクトが果たす役割を示します。たとえば、「顧客」は「請求先住所」を持つといった具合です。
具体例：学生と授業 🎓
学術記録を管理するシステムを考えてみましょう。学生クラスは授業クラスに関連しています。この関連により、学生は授業に登録できます。しかし、授業は特定の学生がいなくても存在できます。学生が退学した場合でも、授業の記録はデータベースに残ります。
- 視覚的表現： 2つのクラスを結ぶ直線。
- 意味： 授業のライフサイクルは学生とは独立している。
- コード上の同等表現： 参照変数、またはデータベーステーブル内の外部キー。
関連を使用するタイミング
2つのエンティティの間にリンクを設ける必要があり、それらが独立して存在できる場合に、関連を使用してください。これはデフォルトの関係性タイプです。確実でない場合は、まず関連から始め、ライフサイクルの依存関係が明らかになったら後で修正してください。
2. 集約：「所有する」関係 🧺
集約は、関連の特殊な形です。これは「全体-部分」の関係を表します。この文脈では、全体のクラスが部分のクラスを含むか所有します。しかし、集約の特徴的な点は、部分が全体から独立して存在できることです。
集約の主な特徴
- 弱い所有権： 「全体」は「部分」のライフサイクルに対して排他的な制御を持たない。
- 独立性： 全体のオブジェクトが破棄されても、部分のオブジェクトは引き続き存在する。
- 視覚的表現： 「全体」の端に空洞（白）のダイヤモンド型がある直線。
- 共有リソース： 複数の全体が同じ部分を参照するような共有リソースをモデル化するためによく使われる。
例のシナリオ：部署と教授 👨🏫
大学の構造を想像してみよう。A 部署は、教授オブジェクトを集約する。部署が全体であり、教授が部分である。
- シナリオ： 部署が解体または統合された場合、教授は存在を失わない。単に別の部署に再配置されるだけである。
- コード上の同等表現： 参照のリストまたはコレクション。部署は教授オブジェクトのリストを保持するが、それらの作成や破棄を排他的に行わない。
一般的な誤解
人々はしばしば集約を単純な関連と混同する。違いは「全体－部分」関係の意味的強度にある。関連ではリンクは単なる接続に過ぎない。集約ではリンクは階層を示すが、厳密なライフサイクル依存関係を示すわけではない。空洞のダイヤモンドが重要な視覚的サインである。
3. コンポジション：強い所有権 🔨
コンポジションは関連の最も強い形である。集約と同様に、「全体－部分」の関係を表す。しかし、部分は全体から独立して存在できない。全体のオブジェクトが破棄されると、部分のオブジェクトも一緒に破棄される。これは排他的な所有を意味する。
コンポジションの主な特徴
- 強い所有権： 全体は部分の作成と破棄の責任を負う。
- 依存するライフサイクル： 部分は全体がなければ意味も存在も持たない。
- 視覚的表現： 「全体」の端に塗りつぶし（黒）のダイヤモンド型がある直線。
- 限定アクセス：部品は通常、一度に一つの全体にのみ属する。
例のシナリオ：家と部屋 🏠
不動産モデルを考えてみよう。A 家は 部屋オブジェクトで構成される。
- シナリオ：「部屋」が「家」によってその文脈が定義されない限り、空間に浮かぶ状態で存在することはできない。家が取り壊されれば、部屋は実質的に破壊される。別の家に移動することはない。
- コード上の同等物： Houseクラスは内部でRoomオブジェクトをインスタンス化する。Roomオブジェクトは外部から渡されるのではなく、Houseコンストラクタの一部として作成される。
集約との比較
なぜ車とエンジンは集約だが、家と部屋は構成なのか？
- 車とエンジン： 車が廃車になった場合、エンジンは取り出されて別の車に取り付けられる可能性がある。エンジンは特定の車のインスタンスを超えて価値を持つ。これが集約である。
- 家と部屋： 部屋は特定の家の壁と位置によって定義される。再構築せずに部屋を分離して別の場所に設置することは意味がない。これが構成である。
4. 比較表（並べて） 📊
明確さを確保するために、3つの関係タイプを直接比較できる。この表は、ライフサイクル、視覚的表記、使用シナリオにおける重要な違いを強調している。
| 特徴 | 関連 | 集約 | 構成 |
|---|---|---|---|
| 関係の種類 | 一般的なリンク | 全体-部分（弱い） | 全体-部分（強い） |
| ライフサイクル | 独立 | 独立 | 依存 |
| 所有権 | なし / 共有 | 共有 | 排他的 |
| 視覚的記号 | 直線 | 空心のダイヤモンド (◊) | 塗りつぶされたダイヤモンド (◆) |
| 例 | 学生 – 授業 | 部署 – 教授 | 家 – 部屋 |
5. 実装とコードマッピング 💻
図は設計図を提供するが、実際の実装はコードで行われる。これらの関係がどのように翻訳されるかを理解することは、メモリの整合性を保ち、メモリリークを回避するために不可欠である。
コードにおける関連
ほとんどのプログラミング言語では、関連は参照変数を介して実装される。親オブジェクトは子オブジェクトへのポインタを保持する。
- 保存: 子オブジェクトのメモリは別々に割り当てられる。
- 初期化: 子オブジェクトは通常、コンストラクタまたはセッターメソッドを介して渡される。
- 破棄: 親を削除しても、子が自動的に削除されるわけではない。
コードにおける集約
集約はしばしば参照のコレクションのように見える。親はコンテナを管理するが、中身は管理しない。
- 保存: 親は子の参照のリストまたは配列を保持する。
- 初期化: 子オブジェクトは別々に作成され、親のコレクションに追加される。
- 破壊：親オブジェクトが子オブジェクトへの参照を停止するが、子オブジェクトはガベージコレクションされるか、別の所有者によって明示的に削除されるまでメモリ上に残る。
コードにおけるコンポジション
コンポジションは、親が子を作成し、破棄することを意味する。これは、ネストされたオブジェクトの作成でよく見られる。
- 保存：子オブジェクトは親クラスのメンバ変数である。
- 初期化：子オブジェクトは親のコンストラクタ内でインスタンス化される。
- 破壊：親がスコープを離れると、子は破棄される。
6. 一般的な落とし穴と誤解 ❌
経験豊富なデザイナーですら、これらの関係性をモデル化する際に誤りを犯すことがある。以下は避けたい最も頻出する誤りである。
落とし穴1：コンポジションの過剰使用
すべてにコンポジションを使用して厳格な境界を強制したくなるが、これによりシステムが硬直化する可能性がある。たとえば「部屋」が「家」のコンポジションで構成されている場合、複雑なリファクタリングを経ずに別の家にその部屋を移動することは難しい。ライフサイクルの依存関係が絶対である場合にのみコンポジションを使用すべきである。
落とし穴2：ナビゲーション性の無視
2つのクラスが関連しているからといって、両方が互いを知っている必要があるわけではない。関連性において、クラスBがクラスAへの参照を必要とするかを検討する。必要でない場合は単方向の矢印を描く。これにより結合度が低下し、テストが容易になる。
落とし穴3：集約とコンポジションの混同
これが最もよくある混乱の原因である。自分に問うてみよう。「親が死ぬと、子も死ぬか？」答えが「いいえ」なら集約、「はい」ならコンポジションである。視覚的な形状にのみ頼るのではなく、ビジネスロジックに基づいて判断すべきである。
落とし穴4：循環依存
関連性を定義する際には、コンパイルを妨げるかスタックオーバーフローを引き起こす循環依存を作らないように確認する。たとえば、クラスAがクラスBを参照し、クラスBがクラスAを参照している場合である。一部の文脈では有効だが、シリアル化やデータベースの外部キーを複雑にする可能性がある。
7. 実際のシナリオとリファクタリング 🏢
これらの概念が複雑なシステムにどのように適用されるかを見てみよう。銀行システムとECプラットフォームを検討する。
銀行システム 🏦
銀行口座システムを考えてみよう。
- 顧客と口座（集約）：顧客は口座を持つ。顧客のプロフィールを閉鎖した場合、口座はアーカイブまたは移管されるが、アーカイブ目的で口座レコード自体は保持されることがある。これはしばしば集約である。
- 取引と口座（コンポジション）：取引は口座に属する。取引は口座なしでは存在できない。口座が削除されると、取引は論理的に削除またはそれに伴ってアーカイブされる。これはコンポジションである。
ECプラットフォーム 🛒
注文管理システムを考えてみよう。
- 注文と顧客（関連）： 注文は顧客によって行われます。顧客アカウントが無効化された場合でも、注文履歴は法的根拠により保持されます。これが関連です。
- 注文と明細項目（組成）： 注文には明細項目が含まれます。注文がキャンセルまたは削除されると、明細項目は関係がなくなる。明細項目は注文内に組み込まれます。
8. モデリングのベストプラクティス 🏗️
明確で堅牢な設計を維持するため、クラス図を作成する際は以下のガイドラインに従ってください。
- シンプルから始める： 関連から始めましょう。ライフサイクルの管理が必要だとわかったら、後で集約または組成にアップグレードしてください。
- 一貫性を保つ： 「部屋-家」に対して組成を使用するなら、同じ図で「窓-壁」に関連を使用しないでください。明確な理由がない限り、一貫性が読みやすさを助けます。
- 多重性を文書化する： 常に基数（1、0..1、1..*）を明記してください。多重性のない関係は曖昧です。
- 端点に名前を付ける： 関係線の端点にラベルを付けてください。「注文」が「項目」を持つという表現は、「注文」と「項目」がつながっているだけよりも明確です。
- ライフサイクルを確認する： 図を定期的に見直してください。要件が変化すると、組成が集約に変わる可能性があります。モデルを現実に反映するように更新してください。
9. データベースへの影響 🗄️
クラス図はしばしばデータベーススキーマ設計を決定します。関係性を理解することで、外部キーの設定や正規化の判断がしやすくなります。
- 関連： 通常、データベーステーブルに外部キーが作成されますが、関係が多対多の場合、結合テーブルが作成されます。
- 集約： 関連と似ています。外部キーは「部品」テーブルに存在し、「全体」テーブルを指しています。
- 組成： 外部キーが作成されることが多いですが、特定の制約が付きます。たとえば「ON DELETE CASCADE」ルールです。親行が削除されると、データベースは自動的に子行を削除します。
これらの違いを理解することで、データ整合性の問題を防げます。コード上で関係を組成としてモデル化しても、データベースでは単純な関連として実装すると、孤立レコードのリスクがあります。
10. テストと検証 ✅
これらの関係に対するユニットテストでは、オブジェクトの状態に特に注意を払う必要があります。
- 関連をテストする： 参照が存在し、有効なオブジェクトを指していることを確認してください。子オブジェクトが独立して存在できることを確認してください。
- 集約をテストする： 親を削除しても子がクラッシュしないことを確認する。複数の親が同じ子を参照できることを確認する。
- 合成のテスト： 親を破棄すると子も無効化または破棄されることを確認する。子は親なしではインスタンス化できないことを確認する。
11. 設計の明確さについての最終的な考察 🧠
クラス図の設計は反復的なプロセスです。システムを構築する過程で、集約、合成、関連の理解を深めていきます。単に線を引くことではなく、意図を伝えることが目的です。開発者が図を読んだときに、オブジェクトがどのように関係しているか、そしてどのくらいの期間生存するかを即座に理解できるようにする必要があります。
独立したリンクと依存するライフサイクルを区別することで、保守が容易なシステムを構築できます。主要なオブジェクトを削除したときに予期しない副作用が発生する状況を回避できます。メモリの管理が効率的になることを保証できます。これらの関係は単なる学術的な概念ではなく、データの流れやアプリケーションの安定性を決定するものです。
多重度を正確に設定する時間を取る。視覚的な記号を正しく使用する。そして常に図をコードの実際の振る舞いと一致させる。モデルが実装と一致しているとき、堅牢でスケーラブルかつ明確なシステムが得られます。