論理的な結束とは何ですか？なぜそれが悪いまたは望ましくないのですか？
coupling＆cohesion のc2wikiページから：
凝集度（モジュール内の相互依存性）強度/レベル名：（悪いものから良いものへ、高い凝集性が良い）
- 偶然の凝集度：（最悪）モジュール要素は無関係
- 論理的結束：要素は、外部モジュールから選択されたものと同様のアクティビティを実行します。つまり、実行する操作を選択するフラグによって実行されます（CommandObjectも参照）。つまり、関数の本体は巨大なif-else/switch on operationフラグです
- 時間的結束：実行される一般的な時間のみに関連する操作（すなわち、initialization（）またはFatalErrorShutdown？（））
- 手続き的結束：それぞれが異なるデータにある、異なるが順次のアクティビティに関与する要素（通常、線形シーケンス境界に沿って複数のモジュールに簡単に分割できます）
- コミュニケーションの結束：同じデータまたは入力を必要とする以外は無関係な操作
- シーケンシャル凝集：重要な順序での同じデータの操作。 1つの関数の出力が次の関数に入力される（パイプライン）
- 情報のまとまり：モジュールはいくつかのアクションを実行します。各アクションには独自のエントリポイントがあり、アクションごとに独立したコードがあり、すべて同じデータ構造で実行されます。基本的に、抽象データ型の実装。つまり、sales_region_tableとその演算子の構造を定義します：init_table（）、update_table（）、print_table（）
- 機能的凝集性：すべての要素が1つの明確に定義されたタスク、つまり1つの操作を実行する関数get_engine_temperature（）、add_sales_tax（）に貢献します
（強調鉱山）。
私は論理的結束の定義を完全に理解していません。私の質問は：
- 論理的なまとまりとは何ですか？
- なぜそんなに悪いラップ（2番目に最悪の凝集度）になるのですか？
機能的特性ではなく技術的特性によって機能をグループ化することになるため、論理的まとまりが悪くなる可能性があります。たとえば、複数のモジュールで構成されるアプリケーションを考えてみます。各モジュールはビジネスドメインを表し、対応するデータアクセスコードがあります。すべてのモジュールにわたってすべてのデータアクセスコードをグループ化すると、論理的なまとまりが生まれます。結局のところ、これはすべてデータアクセスであり、アプリケーションのデータアクセスパターンを評価できると便利な場合があります。ただし、技術ドメインではなくビジネスドメインがモジュール境界を提供するため、これには問題があります。論理的な結束を達成することにより、機能的な結束を失うことになります。通常、ビジネスドメインは、明確に定義された展開の単位を定義し、ビジネスドメインをサポートするための技術的な側面があります。
それがどのように記述されているかから、私はコードを一緒に結合することについて、いくつかのまとまりがあるが、オブジェクト指向を壊すことについて言うでしょう。
例：ポリゴンの面積の計算。正方形の計算と三角形の計算を組み合わせて、input-paramでのみ選択すると、実際の性質を考慮せずに、2つのものを結果によって論理的にグループ化したことになります。