How can I convince them that this is a bad idea?
Potrebbe non essere una cattiva idea.
Ho visto non pochi sistemi in cui ogni evento ha la sua piccola classe di gestore, e i gestori sono stati scoperti e la dipendenza è stata iniettata in fase di esecuzione, causando un disordine abbastanza grande.
Senza sapere cosa devi fare e cosa potresti dover eventualmente fare, è difficile dirlo con certezza. Ma probabilmente è una cattiva idea.
Su i tuoi punti, un po 'come fautore del diavolo (dal momento che il programmatore probabilmente avrà argomenti simili se vogliono mettere tutto insieme).
The single file will become a merge nightmare, since adding any module will require adding logic to the central controller. If two engineers add two different features, one will have to resolve the conflicts in the central file.
Enh, probabilmente è esagerato. Le diverse condizioni saranno nei loro stessi blocchi, limitando l'area di conflitto. Almeno Visual Studio può oggi automatizzare questi tipi di conflitti. Non riesco a parlare con altri IDE.
The central controller file will get excessively long, growing at least linearly with the number of modules, if not N2 with the with the number of interactions between different modules.
Quindi cosa? Dividere il codice in classi diverse sarà almeno così lungo, dal momento che hai aggiunto il sovraccarico di tutta la cerimonia di dichiarazione di classe. Stai ancora facendo lo stesso lavoro, quindi sarà lo stesso codice (tutto il resto è uguale).
The central controller will be highly coupled—since it will have a dependency on every other module in the system—and have very little cohesion, with the blocks of logic only related because they're caused by any two modules interacting together.
Quindi cosa? Anche con un insieme altamente disaccoppiato di gestori di eventi, qualcosa deve sapere che cosa sono tutti e come legarli insieme - e che qualcosa avrà tutti i punti di accoppiamento quanti l'unico grande gestore . Se non altro, dichiarando esplicitamente le dipendenze in un'unica posizione, puoi vedere più facilmente cosa sono e separarle.
The dependencies between different modules will not be explicit, since a single controller will be responsible for handling those interactions.
Eh? Nella normale versione disaccoppiata di ciò che ho visto, un contenitore di Inversion of Control offusca prontamente le dipendenze concrete. Prevedo che le interazioni nell'unico controller saranno esplicitamente in codice piuttosto implicitamente in convenzione o esplicitamente in qualche file di configurazione nascosto da qualche parte.
Writing unit tests for each module, or integration tests between two modules will be impossible without pulling in every other module via the central controller. The central controller itself will be pretty much untestable, outside of end-to-end testing.
Non sempre. Se il gestore di grandi dimensioni non utilizza tutti i moduli per gestire l'evento che stai testando, non è necessario prendere in giro tutti i moduli poiché non saranno utilizzati. Ci vorrà un po 'di attenzione, e potrebbe essere impossibile date le vostre esigenze, ma non un argomento infallibile.
Alcuni altri argomenti comuni:
If someone changes one module, it causes our consumer to update all of them!
A seconda delle tue esigenze, potrebbero comunque aver bisogno di farlo (perché fai la versione dell'intero sistema, perché le dipendenze sono così pervasive che il cambiamento verrebbe a cascata).
If it's in the big controller, we can't reuse/compose modules!
Certo, ma quasi tutti i sistemi che ho visto in questo modo non potevano farlo comunque. Le dipendenze erano troppo pervasive o tra i moduli o su problemi trasversali (registrazione, sicurezza, accesso ai dati, ecc.).
Ma la cosa più importante da notare è che tutti i miei argomenti contrari sono il tipo di "sarebbe equivalente in modo efficace" al codice modulare. Perché passare attraverso tutto il lavoro di mescolare le cose se non fornirà un beneficio chiaro?
E in gran parte, i reclami contro l'unica grande classe sono impatti di violazione del Principio di Responsabilità Unica. È una linea guida ben nota che si è opposta alle critiche e ai rigori del pratico design OO per anni. Ci sono letteralmente decenni di prove da parte dei programmatori meglio di te, io o il tuo collega che dice che fare una classe con più responsabilità porterà a dolore e cattiveria.