モジュール性が良いアイデアなのはなぜですか？
私のチームには、任意のモジュールから送信されたイベントを処理するためのすべての制御フローロジックを取得し、すべてを1つのファイルにまとめたいプログラマーがいます。これにより、すでに複雑なシステムの保守と拡張が容易になると考えています。これは悪い考えだとどうやって彼らに納得させることができますか？
一般的な議論だけでなく、資料を読むための情報源も歓迎します。アイデアの議論も歓迎します。*
これが私がこれまでに得たものです：
- モジュールを追加するには中央コントローラーにロジックを追加する必要があるため、単一のファイルはマージの悪夢になります。 2人のエンジニアが2つの異なる機能を追加した場合、1人は中央ファイルの競合を解決する必要があります。
- 中央コントローラーファイルは非常に長くなり、Nでない場合でも、モジュールの数に比例して増加します。2 異なるモジュール間の相互作用の数で。
- 特定のモジュールの内部状態にアクセスするメッセージ処理ロジックは、関数でラップするか（これは必ずしも悪いわけではありません）、モジュールにその状態を公開させる（これは悪い）必要があります。
- 中央コントローラーは、システム内の他のすべてのモジュールに依存するため、高度に結合され、結合度はほとんどありません。ロジックのブロックは、2つのモジュールが相互作用することによって発生するため、関連するだけです。
- 単一のコントローラーがこれらの相互作用の処理を担当するため、異なるモジュール間の依存関係は明示的ではありません。
- 各モジュールの単体テスト、または2つのモジュール間の統合テストを作成するには、中央コントローラーを介して他のすべてのモジュールをプルする必要があります。中央コントローラー自体は、エンドツーエンドのテスト以外ではほとんどテストできません。
*システムのフローを制御するためにステートマシンを実装することは必ずしも悪い考えではありませんが、プログラムのさまざまな部分をモジュール化する必要があり、それらに関係のない状態や状態遷移を気にする必要はありません。
これは悪い考えだとどうやって彼らに納得させることができますか？
それは悪い考えではないかもしれません。
各イベントが独自の小さなハンドラークラスを取得し、ハンドラーが検出され、実行時に依存性が注入されて、かなり大きな脆弱な混乱が発生するシステムをいくつか見たことがあります。
あなたが何をする必要があるのか、そしてあなたが最終的に何をする必要があるのかを知らなければ、確実に言うのは難しいです。しかし、それはおそらく悪い考えです。
あなたのポイントに、いくぶん悪魔の代弁者として（彼らがそれをすべてまとめたいのであればあなたのプログラマーはおそらく同様の議論をするでしょうから）。
モジュールを追加するには中央コントローラーにロジックを追加する必要があるため、単一のファイルはマージの悪夢になります。 2人のエンジニアが2つの異なる機能を追加した場合、1人は中央ファイルの競合を解決する必要があります。
ええと、これはおそらく誇張されています。さまざまな条件がそれぞれのブロックにあり、競合領域が制限されます。少なくともVisualStudioは、この種の競合を最近うまく自動マージできます。他のIDEと話すことはできません。
中央コントローラーファイルは非常に長くなり、モジュールの数に応じて少なくとも直線的に増加しますが、異なるモジュール間の相互作用の数に応じてN2ではありません。
だから何？すべてのクラス宣言式のオーバーヘッドが追加されるため、コードを異なるクラスに分割するのは少なくともそれだけ長くなります。あなたはまだ同じ仕事をしているので、それは同じ長さのコードになります（他のすべてが等しい）。
中央コントローラーは、システム内の他のすべてのモジュールに依存するため、高度に結合され、結合度はほとんどありません。ロジックのブロックは、2つのモジュールが相互作用することによって発生するため、関連するだけです。
だから何？高度に分離されたイベントハンドラーのセットがある場合でも、somethingは、それらすべてが何であるか、およびそれらをどのように結び付けるかを知る必要があります-そして、何かは、1つの大きなハンドラーと同じ数の結合ポイントを持つことになります。どちらかといえば、依存関係を1つの場所に明示的に示すことで、依存関係が何であるかをより簡単に確認し、それらを分解することができます。
単一のコントローラーがこれらの相互作用の処理を担当するため、異なるモジュール間の依存関係は明示的ではありません。
え？私が見たこれの通常の分離バージョンでは、制御の反転コンテナは具体的な依存関係を即座に難読化します。 1つの大きなコントローラーでの相互作用は、慣例では暗黙的に、またはどこかに隠された構成ファイルで明示的にコードで行われると思います。
各モジュールの単体テスト、または2つのモジュール間の統合テストを作成するには、中央コントローラーを介して他のすべてのモジュールをプルする必要があります。中央コントローラー自体は、エンドツーエンドのテスト以外ではほとんどテストできません。
常にではない。大きなハンドラーがテストしているイベントを処理するためにすべてのモジュールを使用しない場合、それらは使用されないため、すべてのモジュールをモックする必要はありません。正しく行うにはある程度の注意が必要であり、要件を考えると不可能かもしれませんが、確実な議論ではありません。
他のいくつかの一般的な議論：
誰かが1つのモジュールを変更すると、コンシューマーはそれらすべてを更新します。
要件によっては、とにかくそれを行う必要がある場合があります（依存関係が非常に広範囲に及ぶため、変更がカスケードされるため、システム全体をバージョン管理するため）。
それが大きなコントローラーにある場合、モジュールを再利用/構成することはできません！
もちろんですが、私がこのように見たほとんどすべてのシステムは、とにかくそれを行うことができませんでした。依存関係は、モジュール間または横断的関心事（ロギング、セキュリティ、データアクセスなど）のいずれかで広すぎました。
しかし、注意すべき重要な点は、私の反論はすべて、モジュラーコードと「実質的に同等」のようなものであるということです。明確なメリットが得られないのに、なぜ物事をシャッフルするすべての作業を行うのですか？
そして主に、1つの大きなクラスに対する苦情は、単一責任原則に違反した場合の影響です。これは、批判や実用的なOO設計）の厳格さに何年にもわたって立ち向かったよく知られたガイドラインです。プログラマーからは、文字通り何十年にもわたって、プログラマーから、複数の責任を持つクラスは、痛みと悪につながります。
アンチパターンがあります- 神オブジェクト 。
あなたが述べたように、神はオブジェクトします：
- 維持するのは難しい
- 通常、1つまたは複数に違反します SOLIDの原則。
- 新しい開発者には理解できない
- 新しい開発者のために機能を見つけるのは難しい
- ファイル構造を一目見ただけでシステムを説明しない
- 等.
モジュールコントローラーを持っていることは実際にはまったく問題ありません。何かがすべてのモジュールの知識を持っている必要がありますが、そのようなクラスの唯一の責任はそのユーザーにモジュールを提供することです。
モジュールに固有のものはすべてモジュール内にあり、このクラスとは何の関係もありません。
一般的な方法は、このようなクラスを1回記述し、リストファイル（xml、jsonなど）にモジュールを提供することです。モジュールがシステムに追加されても、メインのモジュールコントローラーは変更されません。これは、最初からモジュールから十分に分離されているためです。