組成はカップリングを増加または減少させますか
composition は疎結合の同義語であることはわかっています。
here から読み取りますクラス間の結合が強くなります[〜＃〜] a [〜＃〜]と[〜＃〜] b [〜＃〜]次の場合：
[〜＃〜] a [〜＃〜]は（あるタイプの）[を参照する属性を持っています〜＃〜] b [〜＃〜]。
2つのクラス間のコンポジションを実装するには、説明されているように、一方のタイプの属性を他方のタイプの属性として宣言します here 。
しかし、（3）と上記（2）の引用句が同じであることを考えると、（1）と（2）の間に大きな矛盾はありませんか？
何か不足している場合は説明してください
あなたはあなたの3つの点でいくつかの混乱を引き起こしています：
構成だけでは、結合が失われる保証はありません。コンポジションはインターフェイスへの依存関係を作成するため、事実上いくつかの結合です。しかし、より一般的なインターフェースであるほど、カップリングの敗者になります。
あなたの見積もりは、いくつかの基準の1つにすぎません。 AとBがクラスの場合に適用されます。ただし、Bがインターフェースの場合、同じウィキペディア記事の次の引用が適用されます（箇条書きの後の最初の文）：
低結合とは、単純で安定したインターフェースを介して1つのモジュールが別のモジュールと相互作用する関係を指し、他のモジュールの内部実装に関係する必要はありません
ML構成 は別の表現をします。これは、この関係がどのように実装されているかに関係なく、排他的所有権を持つ部分/全体の関係を意味します（実際には、参照を介して行われることが多いですが、そうである必要はありません。 ）。特にUMLは、所有するオブジェクトの停止は、所有されている要素の停止を意味すると想定しています。したがって、実装の概念（1と2には参照がありますが、所有権についての仮定はありません）をより抽象的な（場合によっては重複します）設計セマンティクスと比較しています。
したがって、単純にするため、そして経験則として（そして 大理石に刻まれた法則としてではなく ）、 疎結合 の場合：
- 継承よりも構成 を優先します。継承は常に強い結合であり（親クラスでの変更はすべての子クラスでの変更が必要になる場合がある）、さらにコンパイル時に定義されるためです。
- 気にする必要のないものに依存しないようにするには、参照する型に interface segregation を使用します。
- 依存性の注入 、特定のタイプの特定のコンストラクターへの暗黙的な依存性を回避するため
カップリングの測定は困難です。
クラス間参照の数などの単純なメトリックは簡単に計算できますが、実際にコードについて有益な情報は多くありません。
カップリングが悪いかどうかを判断するいくつかの要因があります。最も重要なのは：
- 別を参照するクラスがそのクラスの詳細に依存する程度
- 結合先のクラスが変更される可能性のある範囲
- 結合されたクラスが目的に依存しない程度。一緒に変更される可能性が高いクラスは、結合されているランダムな無関係なクラスほど問題ではありません。
これらは定量化することが本質的に不可能であることに注意してください。したがって、これらの重要な要素を無視するため、結合の数値メトリックを信頼しないでください。
継承がより便利なメカニズムを提供し、より多く使用される可能性が高いという理由だけで、構成を使用するクラスから継承するクラスでは、最初のクラスがはるかに悪い可能性が高いことに注意してください。また、多くの場合、より特権レベルで（つまり、保護されたメンバーを介して）対話する方法を提供します。どちらも悪いタイプの結合を増やす傾向があります。したがって、構成を優先することで、カップリングの不良を回避できます。
私のリストの2番目のポイントを減らす傾向があるオープンクローズド原則（そうすることで途方もなく悪いデザインにつながることはありません）、および3番目を改善する傾向がある単一責任原則に従うことを含む他のテクニックは役立ちます。