1

不安定性（I）メトリックによって、パッケージが別のパッケージに依存する必要があるかどうかを知るために使用できる、RobertMartinによって定義されたパッケージ安定性メトリックに類似したメトリックがあるかどうか疑問に思います。

Ca = Afferent Couplings
Ce = Efferent Couplings
I = Ce / (Ce+Ca)

ただし、クラスの場合、パッケージ内のクラスと他のパッケージ内のクラスとの間のAfferentおよびEfferentカップリングではありません。それらは、同じパッケージ内のクラス間の求心性および遠心性の結合（多分および/または他のパッケージ、私は本当に知りません）、その「不安定性」によって、クラスが別のクラスに依存するべきかどうかを知らせます。

編集：おそらく、不安定性メトリックは変更する理由を測定します：比率を変更しない理由ですが、私が考えると、クラスには変更する理由が1つだけあるはずです。つまり、そのような同様の不安定性メトリックが存在する場合、クラスは0になりますが、それでも、一部のクラスは他のクラスのオブジェクトインスタンスを「使用」し、それらをそれらのクラスに依存させます。しかし、私はこれについて確信が持てません、これに関する洞察はありますか？

4

1 に答える 1

1

求心性結合と遠心性結合はクラスの有効なメトリックであり、クラスの不安定性を計算することができます。クラスで Instability を使用して、安定したクラスまたは不安定なクラスの作成に重点を置く場所を決定できますが、実際には、これにより設計上の選択が不適切になる可能性があります。

たとえば、不安定なコンポーネントの依存関係 (求心性結合) はできるだけ少なくする必要がありますが、安定したクラスの依存関係 (遠心性結合) はできるだけ少なくする必要があります。リッチ ドメイン モデルでは、双方向の関連付けが発生する可能性が非常に高くなります。つまり、クラスの意図が安定しているか不安定であるかに関係なく、メトリックに関連付けられた「ルール」に違反し始めているということです。パッケージ/コンポーネント レベルでは、循環的な依存関係は推奨されないか、禁止されていることに注意してください。

パッケージやレイヤーなど、より大きなコンポーネントに集中することに労力を費やすほうがよいでしょう。通常、ドメイン モデルは安定している必要があります (ドメインを変更する場合は、これがドメインの実際の変更、または少なくともドメインの理解を表すためです)。ビジュアル要素やデータ アクセス コンポーネントなど、変更される可能性が高いものは不安定であり、ドメインに依存しています。

于 2011-05-26T23:40:47.310 に答える