Design patterns usage

“What design patterns have you used?”

This used to be the killer question for me at all the job interviews I went to right after graduating from college. I’d stumble and mumble, even though I’d studied them the night before, like with so many previous employers. You’d think that I’d know them by heart! All my poor younger self could do is say that he used the singleton pattern extensively and cross his fingers… It is obvious that what I lacked was practice. I’ve had to self-teach those skills over the years to overcome that deficiency.

Most job postings these days mention that you need some sort of expertise in Design Patterns. I deplore the wording, somewhat, since there are far more patterns than the ones depicted in the Gang of Four book. For example, Design Driven Development introduces a couple of new patterns, Martin Fowler brought in the Active Record pattern with his books on enterprise patterns and Agile practices have their own library of very useful patterns like Dependency Injection, which requires you to use the bridge pattern. This is clearly a fast evolving field where patterns now use other patterns! Having been an active learner in the past two years, I have yet to come across a blog posting on how to use that old bridge pattern. Instead, I see a lot of Dependency Injection patterns articles, or Inversion of Control tutorials.

Separating your implementation from the interface is simply a good practice now. Is it really still a pattern? Do we still need to call it a bridge? And what about dynamic languages like Ruby, where there is no need for such a separation? Some patterns are so trivial to use in some languages that we are using them without even thinking about it.

Patterns are tools that allow us to do our jobs more efficiently, which is why employers keep asking us about them. You plug-an-play them into your object model, tweak them a little, run your tests and voila! It works.

Have you ever used Linq to SQL? Then you have used the unit of work pattern. Do you practice test driven development or behavior driven development? Then you most certainly have used dependency injection to make your system under test work with your mock objects.

I’m also willing to bet my life on the fact that you have used the infamous singleton pattern, where only one instance of the object can exist. I’m also going to go so far as to say that unit testing an object that uses a singleton internally has caused you to cry yourself to sleep.

When you are asked which design patterns you have used in the past, the interviewer typically wants to know if you know your craft’s tools. He wants to know if you’ll spend days, and company money, banging your head against a problem that could be easily solved using a design pattern. Am I personally an expert in design patterns? Do I know them all? No. The important thing is to know they exist and how to use them, and the only way to do that is to stay alert and keep up with what your peers are doing. Of course, a little practice goes a long way, because when the pressure is up and a deadline looms, we all tend not to do what’s right.