組立、組織、合成。 複数の部品を組み合わせ、単に部品を集合させた以上の効果を生み出す。 個々の部品をシンプルに保つことで、構成されたオブジェクト自身をシンプルに保つことができ、 各部品は理解・再利用・テストしやすくなることが期待される。 反面、全体としてアプリケーションの複雑性は増すこととなる。
- 音楽は複数の旋律の組み合わせから構成される。
- 自転車は複数の部品の組み合わせから構成される。
自転車は複数の部品を持つと捉えることができ、Bicycle has-a Partsのようにhas-aという言葉を利用して表現されることがある。 Bicycle is composed of Parts、とも捉えられる。Compositionは、has-aの関係を利用したパターンである。
振る舞いはオブジェクト間に存在し、オブジェクトはクラス間の関係性によって組織される。 Compositionでは、オブジェクトは構造的に独立した状態で存在するが、 メッセージを明示的に委譲しないといけないという点で依存性が存在する (継承の場合は自動的に親クラスにメッセージが委譲されるため、明示的にdelegateする必要は無い)。 Inheritanceに比べCompositionは遥かに依存性が少なく済むため、Compositionが解決できる問題についてはこれを利用すべきとされる。
これはis-a vs. has-aの構図と捉えることもできる。 各インスタンスの詳細を見たとき、ほんの少しの差異しか存在しないのであれば、is-a(Inheritance)が支持される。 より多くの部品が必要となるほど、よりhas-a(Composition)が支持される。
継承は、適切に利用すれば変更のコストを大きく削減することが出来るが、危険な側面も幾つか存在する。 仮に適切なモデルに継承を利用したとしても、後の変更で継承が適切ではくなる場合がある。 2つの機能を継承したくなる場合などが挙げられる。 その場合、冗長なコードを書いて対応するか、または構造の変更に大きなコストを割く必要が出る。 どのように対応するにせよ、これらの対応にはある程度のスキルが必要となる。 不慣れなプログラマがこの問題に直面したとき、適切な対応が取れず、デザイン的な問題を生む原因となり得る (子クラス間で重複したコードを書いてしまう、分岐を増やして不必要な依存性を増やしてしまうなど)。
継承を利用すべきどうかという選択には、その利用者の規模も関係する。 もし自分用の小規模なコード等で利用する場合には、継承はコスト的に優れた解決手段となり得るかもしれないが、 大勢が利用するようなコードを書く場合には、あまり効率の良い解決手段とはなり得ない。 特にフレームワークのような場合には、それを利用する側のオブジェクトが既に継承を利用して親を新規に持てない場合もあるため、 継承させるようなインターフェースを提供するのは避けたほうが良い。
全体を束ねるオブジェクトは、各部品に対して適切なメッセージを委譲する責務を負わねばならない。 Compositionは、非常に似通った部品に対して処理を共通化する手段を提供しにくい(継承の方が得意)。
- 継承は専門化である
- 継承は、既存のクラスの大部分を利用しながら比較的少しのコードを新たに追加したい場合に有効である
- ただの部品の集約より多くの振る舞いを生む場合には、Compositionを使うべき