The bouncer pattern

Last week, J.B Rainsberger talked at Agile Philly about integration tests are a scam and explained to the audience the bouncer pattern.

I am going to paraphrase the concept.

Imagine you own a night club. It’s pretty big with 7 bars around a dance floor. Bartenders must ask for your ID before you get a drink. Some bartenders are pretty good at remembering faces, others not that much. It’s Saturday night and the place is packed. As the night goes on you start to get pissed off at the fact that you need to show your ID for almost every drink. Getting a drink gets slow and sloppy. People stop showing up at your night club.

So you push that responsibility out of the bartenders and hire a bouncer that can check for IDs at the entrance of the club. Now, the bartenders understand that if you are the club, you pass the requirement for drinking. Not only this speed things up, it also minimize the possibility of something going wrong (null pointer if I don’t have my ID anyone?).

So that’s the bouncer pattern. Instead of doing defensive programming all over the code base, check for basic correctness at the edge of the class/module/service. The code becomes easier to read and simpler to maintain.

If we use constructor dependency injection to construct objects/module/service, we can help out our bouncer keep the junk out of our code.