I have a programmer on my team who wants to take all the control flow logic for handling events sent by any module and put it all in a single file, because they think it will make an already-complex system easier to maintain and grow. How can I convince them that this is a bad idea?Sources to reading material are welcome, as well as general arguments. Arguments for the idea are also welcome.*Here's what I've got so far: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.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.Any message handling logic that accesses internal state for a given module will either need to be wrapped in a function (this is not necessarily bad), or have its module expose that state (this is bad).The central controller will be highly coupledsince it will have a dependency on every other module in the systemand have very little cohesion, with the blocks of logic only related because they're caused by any two modules interacting together.The dependencies between different modules will not be explicit, since a single controller will be responsible for handling those interactions.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.* Implementing a state machine to control the flow of a system is not necessarily a bad idea, but different parts of the program still need to be modularized and not have to care about states or state transitions that don't matter to them.
Why is modularity a good idea?
architecture;single responsibility;modularization