The Mega Switch

In a place where I worked, I came to met the TheMegaSwitch programming style, guys there decided that there was no need to define more than one method, or any need to define more than one class, and a need for only the following types as parameters: int, and an array of String, and a List (in this place TheMegaSwitch had around 1000 cases):

 class MegaSwitchGodClass?{


 public List megaMethod(int algorithmNumber, String... arguments)

switch(algorithmNumber){

 case:1
//Do something with the arguments array
 break;

 case:2
//Do something with the arguments array
 break;

  case:2
//Need to REUSE something for case:1?
megaMethod(1,arguments);
 break;

 case:N
//Do something with the arguments array
 break;

}

 }

It is tempting to ridicule TheMegaSwitch, but the big question we should be making ourselves is: What limitations in current languages made this team choose to implement TheMegaSwitch instead of using many of the "services" that the language offers. The interesting thing here is that this approach does gives them some advantages:

No need to refactor method names, because they do not exist and no need to worry about method choosing good names, specially if they are database queries, it can get really difficult to write method names. Example:

 getCustomersWithNameThatEarnMoreThanThatHaveTakenLessSickDaysThanThatHaveBetweenYearsWorkingInTheCompanyAtBranch(String name, BigDecimal earn, int sickDays,int minYears, int maxYears, String companyBranchName).

Now imagine all the method names required for all manipulations required a database with 100 different tables... now sometimes people just do not bother to write meaningful names and just write:

 getCustomers(String name, BigDecimal earn, int sickDays,int minYears, int maxYears, String companyBranchName).

And when you see that being called: getCustomers("Joseph", new BigDecimal("456.45"), 4,1, 5, "NewYork"). But that of course leaves you with lots of questions: What are the "4,1,5" numbers for? what is the BigDecimal for? and what if you do the same with this method:

 getCustomersWithNameThatEarnMoreThanThatHaveTakenMoreThanSickDaysThanThatHaveBetweenYearsThatWereBornAtTheCity(String name, BigDecimal earn, int sickDays,int minYears, int maxYears, String companyBranchName).

after "compression" and "calling" looks excatly like the other: getCustomers("Joseph", new BigDecimal("456.45"), 4,1, 5, "NewYork") but gives completely different results... is this a secondary effect of not using SmallTalk syntax?

No need to worry about parameter types, everything is a string.
No need to worry about the number of parameters, everything is in an array of strings
No need to worry about learning object orientation techniques or patterns.
It is easy to explain: "Need to add some new functionality, just add another case in the switch. Need to use existing functionality? Look for the number in the switch and call the method "megaMethod". Forgot what a number was for? reread the code (after all, most languages and developers do not allow or use really meaningful names, so, what is the difference?)

Have you seen the TheMegaSwitch in a system in your organization? Is it a symptom that dealing with programming is much harder than we typically think, and languages do not make it easy to follow "the recommended and accepted approach"? What would you prefer to have to deal with, a system built with a TheMegaSwitch, or an over engineered JEE-like "lets use a lot of patterns for anything" system?

Oh, and BTW note that the TheMegaSwitch was a medium sized system (around 100 tables, around 100 users) with average success, used in production, and that does its job, as good, or as bad as if it were was built in any other way.

Was this, more than anything, an attempt to make their language more dynamic?

Perhaps, but these abominations sometimes grow organically out of a single, small bit of code employing TheMegaSwitch -- but with only a handful of CASEes that might have had some sound justification at the time, or that was created by a junior developer who didn't know any better -- and a long, long succession of subsequent developers have simply tacked on additional CASEes rather than refactor the lot. Bad code can be like a cancer -- it starts out small and innocuous, but eventually grows to the point of killing the host.

"What would you prefer to have to deal with, a system built with a TheMegaSwitch, or an over engineered JEE-like "lets use a lot of patterns for anything" system?"

Neither. Both are extremes. There's an appropriate middle ground.