全体は部分の合計よりも大きい
-アリストテレス
この言葉はアリストテレスによるとされているものである。 基本的なポイントは、相乗効果の一つです。 スティーブン・コヴィーのベストセラー『7つの習慣』では、6番目の習慣として「Synergize（相乗効果）」を挙げています。 組織で言えることは、コンピュータサイエンスでも言えることです。 モノは個体よりも本体の方が価値がある。 コンピュータサイエンスでは、コンポジションという言葉を使います。
Composition
では、コンポジションとは何を意味するのでしょうか。 “コンポジション “は、オブジェクト指向プログラミングにおける基本的な概念の1つです。 インスタンス変数で他のクラスの1つ以上のオブジェクトを参照するクラスを記述しています。 これにより、オブジェクト間のhas-aの関連をモデル化することができます。” Stackifyではこのように説明されています。 オーケストラのようなものだと考えてください。 9236>
Benefits
適切な構成で作成されたコードの主な利点は、再利用です。 正しく設計すれば、再利用は簡単なはずです。 そうでない場合は、かなり面倒になる可能性があります。 それと同時に、直感的でクリーンな API (Application Programming Interface) も必要です。 経験豊富なJavaプログラマとして、私は、JavaのスレッドAPIの設計を嘆く声を数多く聞いてきました。
Examples
Java で構成がどのように見えるかを見るために、例を作成しましょう。
ここで、Role クラスを定義しました。
Hiding
このAPIの例では、HotDogGrinderとHotDogGrillクラスはパッケージプライベートで、外部からはアクセスできません。
ここで、APIのパブリックフェイス、HotDogMachineがあります。 このクラスは、API デザインで隠している 2 つの内部クラスへの参照を持ちます。
Composition vs Inheritance
構成と継承は、開発者が混同することがあります。 Steven Lowe がこの ThoughtWorks のブログ投稿で指摘しているように、どちらを使用するか慎重に選択する必要があります。 経験則と同様に、経験則が常に適用されるわけではないことを理解する必要があります。
すでに構成について長々と話しているので、継承を定義しましょう。 継承は、オブジェクト指向プログラミングの基礎の 1 つです。 例えば、foodクラスがあれば、breadクラスはfoodクラスを継承することになります。 一方、構成は、より大きなユニットの一部である要素を扱います。
Lowe は、どちらかを使用できる場合、2 つの異なる質問をする必要があることに気づかせてくれます。 まず、”ドメイン概念の表現/実装は 1 つの次元である”。 基本的に、両方が同じドメインにある場合、継承はおそらく最善の策です。 次に、”ドメイン概念のセマンティクスとその関係 “である。 作成したコンポーネントが別のものに転送され始めたら、これは、代わりに継承を使用することを再考する必要がある兆候かもしれません。
構成は、ソフトウェア開発の大きな原則ですが、多くの専門家が台無しにしています。 私自身、正しくアプローチせずにソリューションを作成し、これを実行しました。 2 つのオブジェクトの間に「has-a」関係がある場合、同僚とホワイトボードで簡単に議論したり、紙に何かをスケッチしたりすると、理解しやすくなります。 これを一通り読んだら、あなたもその利点を理解し、例題でどのように使うかを知っておくべきです。 いくつかの例を構築し、それを使用してみて、あなたが正しい道を歩んでいるか、あるいは継承がより良い道かもしれないかを知ることができます。