また、クラス結合は、 CK94 によって最初に定義されたオブジェクト間結合 (CBO) という名前で行われます。 基本的に、クラス結合は、1 つのクラスで使用されるクラスの数の尺度です。 高い数値は悪く、通常、このメトリックでは低い数値が適しています。 クラス結合は、ソフトウェア障害の正確な予測因子であることが示されており、最近の研究では、上限値9が最も効率的な S2010であることが示されています。
Microsoft のドキュメントによると、クラス結合は、パラメーター、ローカル変数、戻り値の型、メソッド呼び出し、ジェネリックまたはテンプレートのインスタンス化、基底クラス、インターフェイス実装、外部型で定義されたフィールド、属性装飾を使用して、一意のクラスへの結合を測定します。 優れたソフトウェア設計により、型とメソッドは高い凝集度と低結合を持つ必要があります。 高結合は、他の型との相互依存関係が多いため、再利用と保守が困難な設計を示しています。"
結合と凝集の概念は明確に関連しています。 この話題を保つために、KKLS2000から簡単な定義を与える以外、まとまりについて深く掘り下げることはしません。
「モジュールの凝集は、Yourdon と Constantine によって、"モジュールの内部要素が互いにどれだけ緊密にバインドされているか、または関連しているか" YC79 として導入されました。 モジュールが 1 つのタスク [...] を正確に表し、そのすべての要素がこの 1 つのタスクに影響を与える場合は、強い凝集があります。 コードではなくデザインの属性としての凝集性と、再利用性、保守容易性、および変更可能性を予測するために使用できる属性について説明します。"
クラス結合の例
実際のクラス結合を見てみましょう。 まず、新しいコンソール アプリケーションを作成し、その中にいくつかのプロパティを持つ Person という新しいクラスを作成し、コード メトリックをすぐに計算します。
このクラスは他のクラスを使用しないため、クラス結合は 0 であることに注意してください。 次に、Person のインスタンスを作成し、プロパティ値を設定するメソッドを使用して、PersonStuff という別のクラスを作成します。 コード メトリックをもう一度計算します。
クラス結合値がどのように上がっているかを確認してください。 また、設定したプロパティの数に関係なく、クラス結合値は 1 だけ上がり、他の値では上がらないことに注意してください。 クラス結合は、使用される量に関係なく、このメトリックに対して各クラスを 1 回だけ測定します。 さらに、 DoSomething() には 1 がありますが、コンストラクター ( PersonStuff()) の値には 0 があることがわかりますか。 現在、別のクラスを使用しているコードはコンストラクターにありません。
別のクラスを使用するコンストラクターにコードを配置した場合はどうなりますか? 次の内容を取得します。
これで、コンストラクターには別のクラスを使用するコードが明確に含まれており、クラス結合メトリックはこの事実を示しています。 ここでも、 PersonStuff() の全体的なクラス結合が 1 で、 DoSomething() が 1 の場合、それを使用する内部コードの量に関係なく、1 つの外部クラスのみが使用されていることを示すことができます。
次に、別の新しいクラスを作成します。 このクラスに名前を付け、その中にいくつかのプロパティを作成します。
次に、DoSomething() クラス内の PersonStuff メソッドのクラスを使用し、コード メトリックをもう一度計算します。
ご覧のように、PersonStuff クラスのクラス結合は最大 2 に上がり、クラスをドリルインすると、 DoSomething() メソッドに最も多くの結合があることがわかりますが、コンストラクターは 1 つのクラスのみを消費します。 これらのメトリックを使用すると、特定のクラスの全体的な最大数を確認し、メンバーごとに詳細をドリルダウンできます。
マジックナンバー
サイクロマティックの複雑さと同様に、すべての組織に適合する制限はありません。 ただし、 S2010 は、9 の制限が最適であることを示します。
したがって、しきい値 [...] を最も効果的と考えます。 これらのしきい値 (1 つのメンバーの場合) は CBO = 9[...]" です。(強調を追加)
Code Analysis
コード分析には、保守容易性ルールのカテゴリが含まれます。 詳細については、「保守容易性ルール を参照してください。 従来のコード分析を使用する場合、拡張設計ガイドライン規則セットには保守容易性領域が含まれます。
保守容易領域の内部には、クラス結合の規則があります。
この規則は、クラス結合が過剰な場合に警告を発行します。 詳細については、「 CA1506: 過剰なクラス結合を避ける」を参照してください。
引用
CK94
Chidamber、S. R. & Kemerer、C. F. (1994)。 オブジェクト指向設計のためのメトリックス スイート (ソフトウェア エンジニアリングに関する IEEE トランザクション、Vol. 20、No. 6)。 ピッツバーグ大学のウェブサイトから2011年5月14日取得: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf
KKLS2000
Kabaili、H.、Keller、R.、Lustman、F.、Saint-Denis、G. (2000)。 クラス・コヒージョン再検討: 産業システムに関する実証的研究（オブジェクト指向のソフトウェア工学における定量的アプローチに関するワークショップの議事録）。 モントリオール大学のウェブサイトから2011年5月20日取得 http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf
SK2003
Subramanyam、R. & Krishnan、M. S. (2003)。 Object-Oriented 設計の複雑性に関するCKメトリックの実証分析:ソフトウェア欠陥への影響(ソフトウェア工学に関するIEEEトランザクション、Vol. 29、No. 4)。
S2010
Shatnawi、R. (2010)。 Open-Source システムにおける Object-Oriented 指標の許容されるリスクレベルの定量的調査(ソフトウェア工学に関するIEEEトランザクション,Vol. 36, No. 2).
YC79
エドワード・アードンとラリー・L・コンスタンティン。 構造化されたデザイン。 プレンティスホール、エングルウッドクリフ、N.J.、1979年。