アプリケーションを設計するとき、オブジェクトが密結合されていることはいつわかりますか? 密結合されたオブジェクト/コードの兆候は何ですか?
5 に答える
2つのオブジェクトAとBを取り上げましょう。
簡単にするために、Aには次のプロパティがあると仮定します。
名前:文字列年齢:整数DateOfBirth:DateTime
Bには次の方法があります。
CreateInstanceOfA(string Name、Integer Age、Datetime DateOfBirth)であり、メソッド引数に初期化された値を持つAのインスタンスを返します。
ここで、Aに新しいプロパティを追加するとします。
StateCode:文字列
今、あなたは問題を抱えています。CreateInstanceOfAを更新して、新しいプロパティを含めますか?その場合、新しいフィールドを含めるために、参照されているすべての場所でコードを変更する必要があります。選択した言語が演算子のオーバーロードをサポートしている場合は、新しいメソッドを追加できます。コンパイルが中断されない場合がありますが、それでもコードを更新する必要があります。さらに悪いことに、古い方法を使用し、作成後に新しいプロパティを手動で設定する必要があります。
息子AとBは本当に緊密に結合されています。
これは最良の例ではありませんが、設計変更の考えられる影響をすばやく確認する方法です。
オブジェクトが次の場合、密結合が発生している可能性があります。
変更するのは難しい。症状: 依存関係の新しいバリアントを作成し、それと通信するたびに、if ステートメントをクラスに追加する必要があります。コード ベースには、おそらくグローバル変数で動作する if ステートメントのフォレストがあり、デバッグと保守が困難になっています。
壊れやすい。症状: オブジェクトのバグが、システム全体で予想外の数の他のオブジェクトに波及する可能性があります。依存関係間の明確な契約がないため、オブジェクトに加えたい変更の結果を予測することは困難です。
再利用が難しい。症状: オブジェクトを別のコンテキストで再利用すると、すべての依存関係とその詳細に沿ってドラッグすることになり、その一部はその新しいコンテキストに関係がない可能性があります。
テストが難しい。症状: 自動化されたテストでは、何かを実行する前にオブジェクトの大きなクラスターを接着する必要があるため、非常に遅くなります。あなたのテストは脆弱です - 1 つのオブジェクトの詳細の変更は、そのすべての依存関係のテスト セットアップに波及し、簡単に赤くなります。
設計の小さな変更が多数の (変更とは無関係である可能性がある) クラスに 影響を与える場合、設計が密結合されていることがわかります。
Class D
他のクラスにいくつかの機能を提供するクラスです。
Class A
、直接使用しClass B
ます。の変更は、 、およびに影響を与える可能性があります。
ここで、 class からのすべてのアクションを認証するように拡張したいとします。影響を与えなければ不可能であり、認証を気にしません。新しい要件のため、全体をリファクタリングする必要があります。 Class C
D
A
B
C
D
A
B
C
その他の例: データベースへの直接アクセス。使用するデータベースの変更は、コード全体に影響を与える可能性があります (たとえば、を使用せずにSQL
ステートメント全体を実行する場合)。ビジネス ロジックは変更されませんが、DB を切り替える新しい要件はコード全体に影響します。DAO
経験則として、特定のクラスが参照する他のクラスの数を数えます。これを調べる方法はいくつかあります。
- インポート (Java)、使用 (C#)、インクルード (C++) などの数。
- クラス内のフィールド/メンバー変数の数
- メソッドへのパラメーターの数
- 間接型参照の数 (例:
a.getB().getC().getD()
)
これらのタイプのいずれかを変更すると、密結合クラスも変更される可能性があります。
デメテルの法則は、疎結合の簡単なガイドラインを説明しています。
実用的な面では、依存関係のマッピングとリファクタリングに役立つ Eclipse プラグインであるLattixも参照してください。