ウィキペディアによると:
懸念事項の実装は、そのコードが他の懸念事項を実装するコードと混在している場合に絡み合います。もつれが発生するモジュールはまとまりがありません。
次の場合、凝集度は低下します。-クラス
に埋め込まれ、そのメソッドを介してアクセスされる機能に共通点がほとんどない。
-メソッドは、多くの場合、粗粒度または無関係なデータセットを使用して、さまざまなアクティビティを実行します。
したがって、コードが絡み合っていると、単一責任原則、オープンクローズド原則などのSOLID原則に違反することになります。
ほとんどの場合、これらの原則はすべて一緒になり、ある原則/ベストプラクティスに違反すると別の原則につながります。
しかし、もつれは必ずしもコードがまとまりがないことを意味するわけではありません。
たとえば、SecurityCheckerというクラスを作成できます。このクラスは、ユーザーの認証を行い、認証に関連するすべてのアクティビティをログに記録します。明らかに、これは認証とロギングである複数の懸念を処理しているでしょう。そのため、それはもつれたクラスになるでしょう。一方、これらの接続は両方とも同じデータセットで動作します。この場合、ユーザーデータ、ログオン回数、ログイン試行回数などが考えられます。したがって、結束性は依然として高い可能性があります。
一般に、これらの原則/ガイドライン/ベストプラクティスのほとんどは、同じ問題をさまざまな観点から見ています。最終的な目標は、全体的な設計がより保守可能で、効率的で、長期的にエレガントになるように、さまざまなコンポーネント/クラスなどの間の依存関係を管理することです。。