ソフトウェアが高度に結合されているかどうかを確認するにはどうすればよいですか？

「高度に結合された」という用語はよく知っていますが、コードが高度に結合されていることを示す兆候（コードのにおい）があるかどうかは興味があります。現在、Java EEを使用していますが、これはどの言語にも適用できます。

編集：

誰もが興味を持っている場合、この記事は参考になります。（IBM）

私の意見では、結合が不十分なモジュールの一番の指標は、二国間の依存関係です。たとえば、Module1はModule2の関数を呼び出し、Module2はModule1の関数を呼び出します。

ほとんどのインターフェイスは単方向である必要があります。呼び出されたモジュールが、呼び出しの一部として返されない情報を呼び出し元モジュールに渡す必要がある場合、メッセージキューなどの何らかのメッセージパッシングまたはイベントトリガーメカニズムを使用する必要があります。理想的には、メッセージパッシングインターフェースへのハンドルは、初期化または登録プロセス中に渡される必要があります。これは、モジュールがイベントが誰であるかを実際に気にしないような方法でインターフェースを完全に抽象化します...したがって、それは分離されます。

別の兆候は、あるモジュールが特定のデータセットに対して他のモジュールを常に呼び出していることです。これにより、実際に誰がデータセットを所有する必要があるのか​​疑問に思うはずです。問題のこのモジュールが他のモジュールに属するデータを常に見る必要があるのはなぜですか？

第三のツールは、いわば「このモジュールを引き出して、他のモジュールに変更を加えることなく交換できますか」と自問することです。

これは決して完全なリストではありませんが、ソフトウェアを設計する際に私が自問するトップ3です。

古いデザインの格言は、「あなたはあなたの友人に触れることができ、あなたはあなたのプライベートに触れることができます。しかし、あなたはあなたの友人のプライベートに触れることはできません。」それは一言で言えばカップリングです。

高度に結合されたコードの兆候には、実装の個人的な詳細を人々に知らせる非常に大きなインターフェース、および「お互いについて多くを知っている」ように見えるオブジェクトが含まれます。密結合のコードにフラグを立てる自動分析ツールがあります。ランダムなものについては、http：//www.scitools.com/features/metricsintro.phpを参照してください。（それがどれだけうまく機能するかはわかりません。Google検索でかなり高くなりました。）

クラスのユニットテストをいくつか書いてみてください。サポートクラスまたはdb / uiのロードを作成/モックする必要なしにクラスを簡単にテストできない場合、それは悪いカップリング/依存関係の確かな兆候です。

また、最良の治療法の1つですが、コーディング中（TDDなど）にそれを行う必要があります。

私にとって明らかな兆候は、すべてが公開されているということです。

もう1つの兆候は、デメテルの法則違反です。これは、流fluentでないインターフェイスに関する過度のthis.SomeObj.SomeProp.SomeProp参照です。

かつて、オンザフライでデータ入力フォームを作成する「操り人形マスタークラス」と呼ばれるものを見たことがあります。他にもいくつかのソフトウェア設計違反があったので、過剰な結合はその懸念の最小でした。

作成したコントロールからデータを取得すると、次のようになりました。

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */

波及効果。

すべての変更は、すべての密結合モジュール全体に波及効果があります。

「Open-Closed」原則は、適切に閉じられておらず、変更が漏れているという点で違反されています。

クラス/パッケージ/ dlls / jars / whatnots間の＃include / importsなどの数を確認します。このグラフを、精神的に、手動で、または何らかのツールを使用して描画してみてください。

• そのグラフが密集している場合（つまり、至る所に多数の接続がある場合）、システムはモノリシックで高度に結合されています。
• レイヤーに明確に分割されていて、レイヤー間での接続がなく、接続が少なく、接続が少ない場合は、モジュール式で分離されたシステムです。

特定の責任がどこにあるのかわからないために機能の実装が不可能であると判断した場合は、システムが密結合しすぎています。

非常に基本的な兆候については、異なるパッケージのクラス間のインターフェイスの数とその使用法を検討することを検討することができます（通常、疎結合コードにはインターフェイスが含まれ、異なるパッケージの個々のクラス間の直接的な相互作用は限られています）、可能なクラス名の数他のクラスをグループ化するために使用（疎結合コードでは、異なるジョブを持つクラス間の実際の相互作用は、インターフェイス関数またはより一般的な/グループ化クラスの関数によって実行されます）またはクラス内のパブリック変数の数（より緩やかに、より少なく/パブリック変数なし） ）。

ほとんどすべてのコードの匂いは、何らかの方法で余分な結合を示しています。カップリングを最もよく示す匂いは「不適切な親密さ」（私の好きな匂い）かもしれません。

測定する別の合理的な方法は、UMLダイアグラムの行をカウントすることです。N個のオブジェクトがあり、それらの間にN ^ N（またはそれ以上）の行がある場合、コードはほとんど最大限に結合されます。N行は、おそらくあなたが手に入れることができる最小限のものです。