Controllers

Lots happening backstage at Tinderbox Six. We’re had 33 backstage releases so far, and a ton of fascinating discussions and wild demonstrations.

Lately, we’ve had a bunch of knotty little problems, all involving complex classes that are close to the user interface and that are, in consequence, quite tricky to get properly under test. Brad Grzesiak has a nice new article on splitting complex controller classes, of which Tinderbox has a few.

The end result of all of these loci of change can be characterized as a 900-line file of application and business logic in a form much resembling spaghetti. And perhaps "900 lines" is too charitable. The only type of file that may have 900 lines is one that is never intended for human consumption—binary files and database dumps.

Some of this is reflex: “spaghetti” is irrelevant, a tired old charge leveled at coding practices of the 1970s. But the underlying point is sound: big classes are hard to understand, hard to maintain, and hard to test.

On the other hand, splitting has its own costs: you may have smaller classes, but now you’ve got lots of classes. It’s easy enough to sprout a new class to replace a method, but if you’re not careful you’ll wake up to find that you’ve got a folder of 90 little classes. Plus 90 little test classes, naturally. A small object is easier to understand than a big one, but is an object with a dozen helper objects, each with its own specialized class, still small?

Again, it surprises me that discussion of issues like these is so thin. The entire monograph literature of TDD and Refactoring will fit on one shelf, and that shelf is going to be full of repetition and even fuller of sample code. Worse, discussion always winds up repeating the same old debate we originally fought over Structured Programming, in which the New Idea must forever be defended against people who don’t want to change what’s always worked for them.

That never gets anywhere: software engineering, like science, advances funeral by funeral.