Swiss Army Knife

I saw an interesting post from Ben Scheirman last Saturday on the separation of concerns with regard to ASP.NET MVC controllers. Apparently, Preview 4 includes a new AccountController that contains some...ahem...less than production quality code. Ben refactors the code and gives it a more professional polish and the story ends happily.

However, what I found most interesting was one of the comments to his post. And I quote:

"I'm beginning to get a distaste for controllers. It seems like too much code in one place."

To me, this is a very interesting comment because it is characteristic of something that I notice quite frequently: people seem reluctant to create new classes even when new classes are required (disclaimer: sometimes "people" means me). They seem to get into a mind set that certain code needs to go in a certain place versus thinking about classes in terms of behavior. I see this from developers across all levels of experience, too.

Unfortunately, this way of thinking leads to an anti-pattern that I like to call Swiss Army Knife. This is the class that does it all and behaves however you need it to behave.

Here's the thing. We all know this is not a good thing. Whether we have a controller, a view, a presenter, a repository, or a whatever, a class is about behavior. It is there to do a specific job. When we notice that our class is starting to exhibit a split personality, we break it into two classes. No need to be afraid. Code is the most malleable substance on the planet. If we don't like the results, we can always refactor and try again. I know this is common wisdom, but it seems that under certain circumstances, we just forget to do it.