C＃-データ駆動型の設計と結合-母は私でいいですか？
私は過去にデータ駆動型設計を使用しましたが、それは非常にうまく機能しました。私が嫌いなのは、他の値に基づいて値を更新する必要がある何らかの形式の文字列が必要な場合です。例：「％yの％xパーセントをエクスポートします」。その場合、クラス内のどの変数が従来の記号％xおよび％yに対応するかを示すために、識別子として機能する追加の列が必要になります。誤解しないでください。これを回避する方法があるかもしれませんが、これはこのスレッドのポイントではありません（ただし、これに対する回答も構いません）。
データ駆動型設計について私が恐れているのは、密結合です。このシナリオの用語を乱用している可能性がありますが、詳しく説明させてください。
テンプレートクラスがある場合、それをベンダーと呼びます。実行時に初期化され、データソース（xml/csv/txtなど）からのデータがクラスのメンバーにフィードされます。密結合の考え方は、あるクラスの別の機能に対する相互依存、依存、および仮定を防ぐことです。
現在、人々は疎結合法としてデータ駆動型設計を宣伝していますが、クラスの構造は、データソース内にどのようなデータがあるかを想定する必要があります。たとえば、それぞれがクラスの変数を表す4つの列があり、新しい列を配置することにした場合、この目的のためにクラスを再設計する必要があります。さらに、そのようなデータソースファイルが欠落している場合は、機能しないクラスインスタンスを処理しています（または、少なくとも設計どおりに機能しない）。
私の質問は、データ駆動型設計は実際にクラス間の論理結合を強制しないのかということです。また、データファイルの解析を唯一の責任とするクラスがある場合はどうなりますか？このパーサーを参照するクラス、データを必要とするクラス（結合）、またはサードパーティのクラスはどれですか？代わりに、これにデリゲートを使用しますか？
私はすべてデータ駆動型の設計に賛成ですが、特定の状況で特定の欠陥に気付かざるを得ません（まあ、完璧なものは何もありません）。余分な列間に既存の列が出力全体を壊すため、設計の観点から維持するのは難しいです。
何が足りないのですか？
乾杯
「カップリング」は、誰もが汚いと思う言葉の1つです。事実、ある程度の結合がなければ、プログラミングは不可能です。重要なのは、良好な結合と不良な結合を区別できるようにすることです。
私の意見では、「悪い結合」とは、論理的な依存関係が存在しない物理的な依存関係がある場合です。つまり、実行しようとしていることに関係がないと思われるコードを変更する必要がある場合、おそらく結合が悪いです。
データ表現を目的とした一連のクラスがあるようです。これらのクラスが永続性のロジックと結合されている場合（たとえば、データをファイルシステムまたはデータベースに格納するためのコードが含まれている場合）、不適切な結合が発生します。ただし、スキーマは論理表現を定義するため、これらのクラスをスキーマと結合することは悪くありません。当然、クラスはその表現と一致している必要があります。