If you follow good design principles and good dev practices and utilize the APIs and SDKS Microsoft has made available within the .NET Framework, you don’t need to know anything about patterns.

There, I said it. You don’t need to know anything about patterns.

Now why would I think this? Well, a few years ago I interviewed for company here in Tucson and had one of the best interviews I’ve ever had. But there was some confusion and the position was in Mountain View, and I’m in Tucson. And I had to decline the position. I was incredibly disappointed. The company was great all the people I had met were great. It was the best of all worlds.

So a couple of months later another position opened up at the same company with another development group. I applied and was asked to come in for an interview. Unlike my previous interview, which was just an hour or so and had felt more like a bunch of engineers hanging out shooting the breeze, this interview as far more formal.

In the first of the five interviews for the day, all three of the software engineers has sheets of papers with questions. After introducing themselves they started on the questions read right from the sheet of paper. Eventually they got to a question on patterns which was pretty simple, “What do you know about design patterns?” I said, “Well, I know about them cursorily as I read about them in a few of the blogs I follow, and I know that are established solutions to common problems, but I can’t think of any patterns off the top of my head.” The person that asked the question looked flummoxed. I’d like to think it was because up until this question I had been answering pretty well.

But I couldn’t answer a question on patterns.

The second and third interviews proceeded in the same manner. They would show up, ask me questions randomly off of the sheets of paper, things seemed to go pretty well until they got to the patterns question. They all asked the patterns question, I always answered the same way and I always got the same flummoxed look. I finished up the last two interviews, with the department head and hiring manager and went home. I was contacted a couple weeks later saying they weren’t interested in hiring me. The only thing that I could point to as a problem was the questions about patterns.

Fine, I need to know patterns. And so I get the ultimate design patterns book, “Design Patterns: Elements of Reusable Object-Oriented Software” by a group of software engineers know colloquially as the Gang of Four. In fact, in Uncle Bob’s papers on SOLID he quotes from the gang of four several times calling them the GoF. Wonderful! I’ve been a success software engineer up until now and knowing all about these patterns is going to make me even better. Right?

The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.

Design Patterns: Elements of Reusable Object-Oriented Software, Section 1.1, What is a design pattern?,Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Okay, so the first chapter is all about what a design pattern is, and how you would select the patterns and when to use them. There’s also a description on MVC in SmallTalk. I mean, I use MVVM regularly as a part of my every day development cycle in UI development, which is an extension of MVC, so I guess it’s kind of cool (for archival purposes?). There is also a brief description of a each of the design patterns in this first chapter.

And there is where it hits me.  You don’t need to know design patterns.  Chances are if you don’t know anything about them and you’re developing in .NET you are already using design patterns and don’t even know it.

So let’s see what the hell I’m talking about:

Creational:

• Abstract Factory: Used regularly as part of MVVM
• Builder: StringBuilder, OleDbConnectionStringBuilder
• Factory Method: Used regularly as part of MVVM
• Prototype: ICloneable
• Singleton: Covered and discussed under the OCP of SOLID

Structural:

• Adapter: Covered and discussed under the ISP of SOLID
• Bridge
• Composite
• Decorator: extension methods
• Facade
• Flyweight
• Proxy: used implicitly, i.e. FileInfo, also Lazy

Behavioral:

• Chain of responsibility
• Command: Used regularly as part of MVVM
• Interpreter: implicit
• Iterator: IEnumerable, yield, implicit
• Mediator: Controller, View Model
• Memento: ISerializable, IXmlSerializable, DataContractSerializer
• Observer: Events, delegates
• State
• Strategy: delegates, Func
• Template Method
• Visitor

Well, I’ll be a monkey’s uncle, the majority of patterns presented by the gang of four I already use in some form. Additionally, both composite and facade patterns, as well as the state pattern, I’ve used as solutions when architecting applications without understanding them to be design patterns, as such. They simply seemed like the obvious answer.

So I’ve decided after reading all about design patterns I don’t need to know about them. Read them yourself. Buy Design Patterns: Elements of Reusable Object-Oriented Software and you’ll see you don’t need to know them. Read the links above and once you understand them you’ll see you too don’t need to know them.

I mean, come on. If I was a horrible software engineer I wouldn’t have accomplished what I have and wouldn’t hold the position I do now. Knowing design patterns won’t make a bad software engineer good. So conversely, not knowing the patterns won’t make a good software engineer bad, right? Didn’t Uncle Bob say something like this?

Following the rules on the paint can won’t teach you how to paint. This is an important point. Principles will not turn a bad programmer into a good programmer. Principles have to be applied with judgement. If they are applied by rote it is just as bad as if they are not applied at all. Having said that, if you want to paint well, I suggest you learn the rules on the paint can. You may not agree with them all. You may not always apply the ones you do agree with. But you’d better know them. Knowledge of the principles and patterns gives you the justification to decide when and where to apply them. If you don’t know them, your decisions are much more arbitrary.

Getting a SOLID start, Robert C. Martin

So I guess Uncle Bob didn’t quite say what I said. He said you should know the principles and patterns. They’re another tool in your toolbox. So why would I think I don’t need to know anything about patterns? How have I gotten to where I am without knowing patterns?

It’s Andy’s fault

I blame Andy. See, I worked under Andy at my last company. Not in .NET but in Java. Andy grokked patterns. He could instantly recognize a scenario and apply the right pattern. It was fluid. Code flowed together. Problems solved. With Andy it was about the application of theory. He was one of the most prolific software engineers I’ve ever known. But here is what will really blow your mind, it was quality, clean, well-designed code. He was a truly incredible engineer that I learned an incredible amount from.

I learned design patterns but without understanding them as design patterns. Under Andy I learned that given problem X do solution Y but understand there will be constraint Z. I learned this by working in Andy’s code, extending it, fixing bugs (yes, even the best occasionally have bugs), being a dwarf standing on the shoulders of a giant. And then writing my own code under Andy’s review, having him point out problems and solutions.  Okay, so maybe it’s not really his fault.

I took what I had learned under Andy and starting applying it to doing development in .NET, recognizing parts of the framework that fit to a given pattern and applying it as the correct solution. When I use events in WinForms dev do I need to know that it is the Observer pattern? When I use a DataContractSerializer to write out files for serialized objects do I need to know that this is the Memento pattern? When I use a command in MVVM do I need to know it’s part of the Command pattern?

But ultimately this is the flaw to my argument.

• It presupposes that we all work in .NET environment.
• That we’re all developers who work in such a limited scope.
• That we don’t need to think outside of the tray of ideas Microsoft has provided.
• That Microsoft has provided for all problems.

Microsoft has applied design patterns to arrive at solutions that try and make our jobs easier but it doesn’t solve all my problems. As a software engineer I should be expected to be able to apply those ideas to any language and environment. Limiting myself to just the .NET environment does a disservice to myself. I am not merely a code monkey. I do more than just write code. I engineer systems. To do so I must understand design principles and patterns and I must be able to apply design principles and patterns in such a manner that makes the use and extension of that code easy to work with and maintain and that strives for a minimum of deficits.

So to bring this full circle, I had a bad interview, boo hoo. In the first interview it was more about how I would solve different scenarios and I gave solutions that I would later understand to be patterns. In the second interview it was a bad format with bad questions. I was blessed with a mentor who guided my early career in such a manner that I was taught sound design principles and patterns. Unfortunately we are not all blessed. And that is why you need to know design patterns.

Good design principles and patterns aren’t nearly as rampant as one would hope.

Start being part of the solution, understand, use and apply design principles and patterns.  Make your life easier.  Which by extension makes my life easier.

Thanks,
Brian

Image credits:
Abstract Factory
Template Method
Factory Method