CKメトリクス

オブジェクト指向設計の構造上の複雑度を計るメトリクスとして、CKメトリクスというのがあるらしい。
CK とは、Chaidamber(チャイダンバー)さん と Kemerer(ケメラー)さん の頭文字を合わせたものだとか。

WMC(Weighted Methods per Class)

計測対象クラスの重み付きメソッド数。

求め方

クラス内のメソッドに複雑度の重みを掛けて足し合わせたもの。
メソッドごとの複雑度のデフォルト値としては1を用いるが、メソッドごとに複雑度を求めて足し合わせる場合もある。
メソッドごとの複雑度を求める方法としては、McCabe の CC(cyclomatic complexity) や LOC(Lines of Code in Method) があるとか。

利用

値が大きい場合は、クラスが大きすぎると判断し、分割を検討する。

LCOM(Lack of Cohesion of Methods)

計測対象クラスの凝集性の欠如

求め方

インスタンス変数を利用するメソッドの数をもとに求める。

  • 考え1:(本来はこっちらしい)
    • 「利用インスタンス変数が全く重複しないメソッド数」-「利用するインスタンス変数が1つでも重複するメソッドの数」
    • ただし、0以下の場合は0とする
  • 考え2:
利用

考え1の場合は、値が0に近づくほど複雑度が増す。
考え2の場合は、値が大きいほど複雑度が増す。

NOC(Number of Children)

計測対象クラスのサブクラス数

求め方

クラスの直接のサブクラス数。
extends のみを数え、implements を数えないと思われる。

評価

本では、値が高い場合には抽象化が弱まっているとあるが、訳者同様、私もそう思わない。
高い場合には、テストの必要性が高まっており、再利用性も高い。
再設計を検討すべきという記述にも、?である。

DIT(Depth of Inheritance Tree)

計測対象クラスの継承の深さ

求め方

継承ツリーの深さ。
おそらく、フレームワークやライブラリで提供されているクラスの継承は含まず、作成したアプリケーションの継承のみを数えると思われる。

利用

値が高ければ、設計の複雑度が高いが、再利用性も高い。

CBO(Coupling Between Object Classes)

計測対象クラスに関係しているクラス数

求め方

他のクラスが該当クラスに依存する度合い。
※他のクラスのメソッドが該当クラスのメソッドやインスタンス変数を使用している場合、「依存している」という。
本には、逆の依存度も記載されているのだが、別々のメトリクスとするのか、合計の値を評価するのだろうか?
(該当クラスが他のクラスに依存する度合い。)

評価

値が高い場合、

  • 複雑性が高い
  • 保守性が低い
  • 再利用性が低い(?)

RFC(Response for Class)

計測対象クラスに関係しているメッセージ数

求め方

あるクラスがメッセージを受け取った際に「直接」に実施する可能性があるメソッドの数の和。
「該当クラスのメソッド数」+「直接呼び出すほかのクラスのメソッド」

評価

値が大きいと複雑度が増す。