私はカップリングのメトリックを調べており、 DSMも調べています。
私が使用してきたツールの 1 つは、配布の単位であるモジュール (この場合は .net アセンブリ) との「モジュール」間の結合を調べます。
配布単位よりも、パッケージ (または名前空間) 間の結合に関心を持つべきだと思います。
パッケージ/名前空間間の結合にもっと関心を持つべきですか (抽象化は抽象化のみに依存し、具象型は抽象化に依存し、リファクタリングと拡張が容易になるように依存関係に循環がないことを確認してください)、または私ができるかどうかに関心を持つべきですか?変更されていない配布単位を更新する必要なく、新しいバージョンを展開できますか?
他の人は何を測定しますか？
価値があるのは、パッケージ/名前空間のカップリングに焦点を当てれば、ディストリビューションのカップリングのユニットが無料になるか、少なくとも簡単になるというのが私の直感です。
まず、依存関係とカップリングを見て、やり過ぎてしまいがちです。複雑にしすぎないようにしてください。
その免責事項が邪魔にならないので、ここに私が提案するものがあります。
依存関係/結合管理には、実際には 3 つの異なるビューがあります。1) 物理構造 (つまり、アセンブリの依存関係) 2) 論理構造 (つまり、名前空間の依存関係) 3) 実装構造 (つまり、クラスの依存関係)
大規模なアプリの場合、少なくとも 3 つすべてを調べる必要がありますが、通常は優先順位を付けることができます。
クライアントにデプロイされたアプリの場合、1 番が非常に重要になる可能性があります (つまり、プラグインなどの場合)。企業内 (つまり asp.net) に展開されたアプリの場合、通常、項目 1 はそれほど重要ではありません (複数のアプリで再利用されるフレームワークを除く)。通常、#1 の複雑な構造のオーバーヘッドがかからないように、アプリ全体を簡単にデプロイできます。
項目 2 は、保守性の問題である傾向があります。レイヤーの境界と名前空間との関係を把握します (つまり、名前空間ごとに 1 つのレイヤーを実行しているか、論理レベルで異なる方法でパッケージ化されていますか)。場合によっては、論理的な依存関係の構造を調べることで、レイヤーの境界を強化するのにツールが役立つことがあります。
項目 3 は、クラスを適切に設計することです。すべての優れた開発者は、自分のクラスで適切な依存関係のみを引き継ぐように、かなりの努力を払う必要があります。これは言うは易く行うは難しであり、通常は時間をかけて習得する必要のあるスキルです。
質問の核心に少し近づくために、項目 1 は、VS ソリューションでプロジェクトがどのように配置されるかについてです。したがって、これは測定する項目ではありません。それは、最初にセットアップして実行するものです。項目 2 は、ビルド中にツールを使用してチェックし、開発者がルールに違反していないかどうかを確認するものです。それは実際には測定というよりチェックです。項目 3 は、実際に測定をよく検討したい項目です。大量のカップリングを持つコードベース内のクラスを見つけることは、今後の問題点になるでしょう。それらのクラスの品質を確保してください。また、このレベルで測定すると、コードベースが進化するにつれて、コードベースの品質 (全体) についてある程度の洞察を得ることができます。さらに、誰かが本当に不潔なコードをあなたのコードベースにチェックインした場合、危険信号を発する可能性があります。
したがって、優先順位を付けたい場合は、#1 と #2 をざっと見てください。彼らがどのように見えるべきかを知ってください。しかし、ほとんどのアプリでは、項目 #3 に最も時間がかかるはずです。
もちろん、この回答には巨大なフレームワーク (.NET BCL など) は含まれていません。それらの赤ちゃんは＃1に非常に注意を払う必要があります. :-)
そうしないと、次のような問題が発生し ます。 asp
フレームワークが GUI ライブラリに依存するため、Windows Server 2008 の GUI なしのインストールで .NET を実行できない場合...
最後に 1 つ。適切な依存関係/カップリング管理の背後にある原則に精通していることを確認してください。ここで素敵なリストを見つけることができます：
配布単位間の結合と依存関係のサイクルは、プログラムの展開を非常に困難にする可能性があるため、より「致命的」です。また、プログラムのコンパイルさえも非常に困難にする場合があります。
おおむね正しいです。コードを論理的なパッケージに分割し、明確で事前定義された依存関係のみを提供する優れたトップレベルの設計は、ほとんどの場合に役立ちます。唯一欠けているのは、パッケージをディストリビューションの単位に正しく分離することです。