Sometimes you have to bear witness to particularly interesting software formations. So here goes.

Picture a pricing library with about 200 top-level API functions. These ranged from simple formulae, to building structures of interest rates out to 20 years.

The developer ''deliberately'' structured it so that ''every'' non-trivial function passed through a single MonsterSubroutine that I always thought of as GrandCentralStation : 48 parameters (with nothing particularly in common), hundreds of lines, local variables being used many times for completely unrelated purposes. The lines of control would then diverge again and do their separate things.

The bit I still find difficult to figure out is exactly ''why'' everything had to pass through this central point? It actually made the developer's life harder to make this the case, but there was clearly some kind of driver getting him to behave this way.

So, out of interest: has anyone else encountered their own GrandCentralStation? And, no, a big switch statement in a MicrosoftWindows C program doesn't count...

''It probably started out small and simple and grew over time without being cleaned up.''

Oh, no!  It's the MasterControlProgram from TronMovie!
----

One possible justification I could think of (and it's not a very good reason), is that the programmer who did this wanted their own RPC mechanism.  The various exposed API functions are like RPC stubs (they marshall their parameters), and the GrandCentralStation is one giant skeleton, with the actual implementations coded inline.  In theory, by turning all them parameters into a big giant struct, you could send the struct encapsulating the parameters over the network, and it's a trivial matter to unpack the struct and call the GCS function.

Another possible justification (also not a good one), is that there is some CrossCuttingConcern (logging, synchronization, or even cheap debugging support) that the programmer didn't want to replicate across 200 API calls; so he took the PathOfGreatestResistance and found a solution requiring even '''more''' work.

Again, neither justification is justifiable; at least not in my view.

----
A third justification.  If the GrandCentralStation is a solution to the problem in every possible variation, then the other subroutines solve the more everyday problems by setting some of the variables for you.  For instance, if I was writing a physics simulator, I might have a general calculate_position() function which took in a slew of arguments, including the local gravity vector.  I would then have a calculate_position_in_earth_gravity that would set the gravity vector to 9.8 m/sec^2 "down" and call calculate_position, or a calculate_position_in_microgravity() that would set the gravity to zero and call calculate_position().

----
CategoryAntiPattern