Problem Domain for Design Patterns

Question

I was asked during an interview for an entry level coder position about how much I knew about design patterns.

Actually, the interviewer brought out a hard-cover book (Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and asked me, enthusiastically, if I had read it.

I know this is a classic programmer text, I recognized the book of course. I had to answer "no, I haven't read it," and when he continued to ask me about specific patterns that I should at least be familiar with, I drew a blank.

I should have at least cited the Observer pattern, which I was very familiar with and have used in many of my own programs (in writing Java Swing GUI applications where you have to define a Listener to react to a button press, for example). But I didn't know then the actual name of a pattern like this.

My specific question is:

Are design patterns only useful to know in large-scale, "enterprise"-type applications, where you have to communicate with a large team of programmers? I understand one of the benefits of knowing pattern names is that its a good way to communicate high level ideas to other programmers.

To be more precise, are design patterns useful mainly in the problem domain of large scale web-application development, working on a large (say 10+ members) team?

Answer 1

To be more precise, are design patterns useful mainly in the problem domain of large scale web-application development, working on a large (say 10+ members) team?10+ members) team?

The answer to any generalization like this is usually a safe no, and this is no exception. Design patterns can be useful on any size of project. I'd like to point out the RAII pattern (acquire resources in the constructor, free in the destructor) in C++ is extremely useful on any size of project. As is the observer pattern, the iterator pattern (those two are really two sides of the same coin, push iteration, and pull iteration respectively.) Likewise implementing a state machine by using polymorphism (State design pattern?) is useful on projects both large and small. It really depends, as in all things, on the specific circumstances and problems, not on whether the project is large or small or how many developers are working on it.

Answer 2

No, patterns can be handy at any level, from small to large. However, there are so many patterns with various overlap that discerning between them is increasingly harder, and to be frank, a lot of what you do probably fits into some pattern with some name you won't recognise. If you can remember the name of the pattern then maybe it's useful, but when it comes down to it, it's all about being good at it. Patterns is a way to recognise stuff to make sure you're not doing something stupid, or are doing something that people agree is clever.

I've seen an over-emphasis on patterns that totally destroy good productivity. It's ok to have an architect with some degree of expertise in some of this, and of course everybody should be aware of some of the most prevalent ones, but seriously, if you're hired on your knowledge of patters, stay clear.

As to big enterprise projects benefiting from patterns, nope, no such thing. It all comes down to developer's skills, and not a recognition of what those skills are called.

Answer 3

Design patterns will be useful anytime you have to need to write an application that has a whole or part that's been done before and that someone identified a good approach for. Design patterns are useful for small applications just as well as enterprise sized applications but in general they are more important for larger apps, web or otherwise, where the consequences of a bad design are more costly.

With modern language frameworks such as .Net and Java a lot of historical programming pain points have been identified and the optimal design identified to solve them, for example MVC, factories and MVVM to name a few. In many cases these frameworks provide a guide to application development that is a lot more relevant than a identifying design patterns.

Answer 4

What matters is not knowing design patterns, but understanding them and thus the principles, that lie beneath them. This understanding is a benefit in any domain (sometimes even outside software development) and can (and should be) applied directly in most scenarios.

I found SOLID and GRASP to be two very strong sets of principles, that can be recognized in many design patterns. If applied to a problem, that can be solved by a pattern not known to you, your solution will often be similar, or sometimes different, but just as elegant.

I encounter a lot of people using patterns without understanding or even thinking. This is not good. In any domain. Patterns can soon become a hammer in search of a nail, thus actually degenerating into anti-patterns. I have a profound hate towards pattern-cultism. Many of these people are too dumb, too lazy, too unexperienced or too narrow-minded to think on their own. Patterns are not an alternative to thinking. They are an alternative to solving the same problem over and over again. They should be treated as such.

Also, I expect of a good developer to be capable to solve problems of higher complexity and larger scale than those addressed by design patterns. I think, if you can demonstrate that capacity, and if you can show understanding of fundamental design principles (and to show them in a pattern previously unknown to you), then you're most certainly above average and worth hiring.

greetz
back2dos