I don’t know how I managed to do it, but up until a couple of weeks ago I’d never heard of software design patterns, but now I’m seeing the term kicked about everywhere. Of course I’ve been spending a lot of time exploring PHP and the Zend Framework, so maybe that’s skewed my observation. Still people are talking about things like the MVC pattern like some would talk about Fruit Loops, “Oh, yeah, Fruit Loops. Well, they’re OK but not for most meals.” I get the feeling that ever other programmer has been talking “design pattern” talk in secret and I’ve been the only one left out.
So what’s up with this? When did the whole design patter concept become dinner conversation for programmers? I’ve read enough to know that it all started with the book Design Patterns: Elements of Reusable Object-Oriented Software published in 1994, but how long has it been part of programmer parlance?
Or is this just one of those phenomena where you learn a new word and suddenly you see it everywhere, and you realize you’ve just been reading past it all that time?
And is this the geekiest question ever asked on SDMB?
I am a database developer and a development manager for a mega-corp. That link had so many key words that it made my head hurt. I think we use a lot of this philosophy but maybe not for all I know. We just build somewhat standardized solutions across many platforms and clients. I have never heard the term “design patterns” before. It sounds like one of those terms that is so highly abstracted that it has little relevance to practical business problems.
“Design patterns” is market-speak for common sense when it comes to programming, especially object-oriented programming.
For example, say you’re writing a web application. Common sense would tell you to create separate, modular components to handle the data, handle the application logic, and handle the presentation to the user. In design pattern lingo, this is a model-view-controller pattern.
The various publications about design patterns give these kind of strategies names which makes them a little easier to talk about, and provides a nice reference for some thorny problems that may not have obvious solutions. For example, class factories are a type of pattern that I have found useful for writing a user-configurable plugin framework. Now I could have just said, “OK, there’s a config file, and it specifies which plugin to use in which situation, and there’s one master class that reads the config file, and it has wrappers that call the right constructor, and every other thing in the system has to use the wrapper instead of calling the constructor directly, so you get the right plugin class!” But instead I just said “class factory” and everybody knew what I meant because we had all read the books.
My favorite one is Code Complete by Steve McConnell, which also touches on numerous other important subjects like unit testing.
I think that’s a bit harsh. It’s a bit more than just “common sense” - Wiki defines a design pattern as
Some of them are simpler than others, but what makes a design pattern useful is, I think, that they’re solutions that have been tried and used in a wide variety of situations, and they are elegant ways of solving common problems. I think you’re doing them a disservice by calling them just “common sense”. I’m not saying that they are the be-all and end-all of design, and it’s easy to overuse them, but they have their place and are useful.
I suspect that “design patterns” as used has more to do with things like Six Sigma and such than things like “OOP is good” or “Goto is bad.”
If I was going to buy a book on good techniques for large/ditributed/what-have-you programming, I’d be looking for something with that in the title. Anything with “design patterns” in the title I’d ignore and assume is something invented so that programmer managers* can BS their superiors away.
Programmers tend to not be fond of managerial positions and will often try to avoid conflict wherever possible as their first priority, at the expense of schedules and common sense. Obviously not all of them (e.g. Bill Gates), but as a generalaity.
So when did the term enter the mainstream programmers’ vocabulary, or has it?
My suspicion is that it’s one of those concepts that is now being taught in school so that everyone with a degree in CS since about 2000 has been immersed in the “pattern” terminology, while everyone older than that just goes, “Huh?”
My last college course in CS was in 1970, and relational databases hadn’t hit the mainstream at that time. When I started reading about relational theory, normal forms, tuples, etc. I was overwhelmed and was having a hard time grasping the basic concepts. Finally I came upon an article that, after talking about Third Normal Form, and candidate keys, and many-to-many relations, said something like, “So, for anyone who has designed more than a couple of databases you may be wondering how this is any different from what you have already figured out by trial and error. Well, it’s probably not that different. This relational jibber-jabber just formalizes what most of us have been doing instinctively for years.” That was a slap-my-forehead moment for me. It sounds like the same thing’s going on here.
The author’s try go to great lengths to distinguish “their” stuff from the general skill set of everyone else. In particular, design patterns are “different” from algorithms. Okaaay.
It is only popular with a small segment of not-too-bright managers. The original authors themselves only recently came out with a new book. Hardly anyone else has written books on the topic. (Not counting non-design pattern books that throw in the term somewhere in order to sell more books.)
I can assure you that hardly any Computer Science programs even mention the subject. (They cover a lot more, just not using the terminology.)
The problem is that you can teach people how to solve 20 common problems. But they go out into the programming world and find that their particular application requires frequently solving a different set of 20 common problems. So, the emphasis needs to be on meta-problem solving. How do you recognize and approach tasks that you’ll need to solve on a regular basis?
I read the original Design Patterns book pretty soon after it was published (1995 or so) and I’ve used some of the patterns.
I think they’re somewhere in between common sense and fancy technobabble. Most of them are just formal descriptions of things that most coders come up with on their own. There’s some nice little tricks (I’m not sure I would have come up with the private constructor in the singleton on my own, for example, but it’s not out of the realm of possibility that I would) and there’s some things that might prove to be useful ideas if you were to consult the book while designing a piece of software.
Overall, though, I’ve found that not many of the patterns are useful in the real world. Some are - and I’ve used them a lot - but others? Way too specialized for whatever I’ve happened to be doing.
I think the strength of the book is that it describes the common patterns and designs and puts a name to them, so that people can use the short hand during design meetings.
Basically. The idea behind design patterns is that we’re trying to come up with a list of designs that have worked well to solve common problems in a lot of situations, and refine the details so that people designing a new system can benefit from what previous system designers have learned. It’s certainly possible to go overboard and apply six different patterns to every problem no matter how simple (many Java programmers seem to love this idea), but applying one or two judiciously can save you a lot of trouble.
The original book is still worth having, but as time has passed, it’s become very clear that some of the patterns they describe are very useful, while others are more specialized. Head First Design Patterns is a little more user-friendly take on the 10 or so most common patterns. Anyone who’s been programming for any length of time should be able to come up with examples of the patterns in that book from their own experience.
This is one of the first books on the subject. It is an amazingly dry and boring read. For all that, some of the ideas were interesting, while the truth is I had been using most of the patterns most of my career.
What I like about it though is it provides a common vocabulary when talking about a design (as long as the others in the room have also read the book.) If you talk about building a singleton or a factory class you don’t have to explain what you mean by those terms. I wouldn’t say it changed the way I develop or think about developing, but it has changed the way that I communicate about developing.
Well, I certainly wouldn’t describe most design patterns as algorithms. They are more closely related to data structures, but they have to do with the structure of your code and class relationships instead.
I suppose you could think of it this way. A good CS program has a course or two on data structures: you learn the differences between a linked list, a binary tree and a hash table, for instance, and when it’s best to use one or the other. Design patterns are analogous, but have to do with how your classes interact with one another, rather than how your data is arranged in memory.
I think design patterns are very real and very much in use by the better programmers. It’s true that some of the very simple ones are just common sense and any decent programmer would use them without even realizing it, or that the technique they are using has a name.
However, there are more involved ones that are worth studying and being familiar with, that are not automatically intuitive. Likewise, some of them are actually hard to understand and it seems to be unclear when they’re ever used at all (see “Bridge”).
Whenever I interview for a (OO) programming position I ask about design patterns and in almost all cases the stronger candidates are familiar with them. (And that’s not because I think they are strong due to their familiarity with design patterns.)
I’m 32 and have a CS undergrad degree, and never learned about patterns until entering the workforce.
Patterns are to algorithms what sequence diagrams are to flow charts. It’s an expansion of a basic concept to take into account the greater conceptual sophistication of software today compared to the 1950’s.
I have been in this business 28 years. I have worked in a couple of organizations where design patterns were an important part of the culture and heard frequent references to the “Gang of Four” (the four authors of the first popular book referenced by the OP), starting shortly after that book came out.
The design pattern concept really took off with that book plus the popularity of OOD and C++. Subsequent books came out specific to Java.
However, nothing is new under the sun. Lots of people have done this kind of thing at the code or design level, they just never wrote a book about it. Once spectacularly obscure example is George Cherry. He was trying to take advantage of the Ada wave back in the late 1980’s to early 90’s. Rather than publishing a book, he thought he could corner the market with proprietary courseware and consultation specific to Ada. His material included what he called idioms, his word for design patterns. It was really good stuff but reached a very limited audience, because one guy can only teach so many classes. Then his chance at success faded with the language he had so tightly tied himself to.
One nice effect of design patterns is that things are named a bit more consistently by people who read the books. Like a factory will be called WhateverFactory, because someone knows that it’s called a factory.
>“Design patterns” is market-speak for common sense
>I think that’s a bit harsh. It’s a bit more than just “common sense”…
I agree with Dervorin, it’s more than just “common sense”.
As a beginning OOP programmer I like what this approach does. Here’s what I think I’ve learned as I picked up a little C# and Java and C++, which are similar enough that the overall structure of a program in any one of them is visible to anyone who understands any other of them. The patterns are overall structures that keep turning up as useful approaches. Nobody has to read these books to become a great programmer, but almost anybody would derive some value from it, I think.
Check out the book “Refactoring” by Fowler (who has other materials out there too). In this book, you can see programs that fit one pattern getting improved by being recast in terms of another pattern. The patterns become a means of naming a structure to discuss it with others, and familiarity with many patterns lets the use of an alternative one occur to a programmer quite easily. Thinking about, referring to, and trading up from a structure are all more work to do without having thought about patterns as patterns.
These two statements capture the biggest purpose of formally talking about “design patterns” instead of just assuming everyone with half a brain can come up with them on their own. I’ve had the experience where, as a junior coder, I was talking about a design and I kept touching on the subject of the particular way in which one specific class was used for creating instances of another class, and someone more senior basically said, “so it’s a factory; yeah, I get it, you don’t have to keep explaining it.” The light went on: this technique has a name, and I should probably know it. Imagine you were building a car and you were unaware of the term “transmission”, so you kept describing the function and/or design of the transmission instead of just saying “transmission.”
And this is the other purpose. Using the simpler and more obvious patterns to establish that patterns themselves are interesting and useful to talk about, you then have a framework for moving beyond the intuitive ones and learning from others’ experience of working through difficult problems. When I read about a pattern that I can’t quite see a use for, I just assume that someday, I might run across a problem that makes that pattern ‘click,’ and at that point, I’m going to go look up the pattern, use it, and not reinvent that particular wheel.
Along with that, it can help get people past the “I’m so clever, I invented something that does X, aren’t I cool” phase more quickly, and moves them towards considering further improvements, caveats, and outright flaws they might have to discover the hard way otherwise.
For example, when someone says “I have this great idea, I’ll have a class where instead of creating a new instance on construction, it just re-uses an existing one, and you won’t even know!” I can say, great, that’s a singleton, and generally should be avoided due to very well realized problems with that design. What are we going to do to avoid these problems? Is it even worth doing this way?
I guess this is why I find anti-patterns to actually be more useful on a regular basis, as frequently it’s easier to sniff out bad design than it is to try and shove a good pattern in. Enough people have slapped their foreheads on the same problems over the years that it’s worth looking to see what they figured out before you invent something clever, and a reasonable understanding of design patterns can help that.
On the other hand, many of the classic patterns do seem to exist as ways to get around java or C++ limitations, which may not apply well to other areas. As with everything people get carried away, particularly on blogs.
I really hate how the emphasis is on the 20 original design patterns from the book of the same name. It makes the whole concept very specific, when in fact there should be hundreds of various “design patterns”. A lot of different books should exist, and it would really expand one’s thinking to reading a few of them and see some clever ways to exploit your given language.
Alas, that’s not how things are now. The phrase, I think, would be deserving of its buzz if they were.
Btw, ‘true’ design patterns should be closely linked to the language, because they’re in fact a form of “syntax” that didn’t make it into the language. OOP was actually a design pattern in C before C++ was created. You would use structs, pointers, and function pointers to do methods, inheritance, and polymorphism! The current 20 were designed for C++, while advanced languages like Ruby can and should use a very different set. Books on the clever patterns you could do in Ruby would form the foundation of the generation of langauges to follow it. Ugh, I really wish “design patterns” were what they claim they are!
Oh, and the other thing that really pisses me off about the current “patterns.”
If the aim is communication, then there should really exist more intuitive, less pompous names. Right now the names are like most names in psychology or most other academic fields: contorted to sound cool and impressive at the expense of accessibility. “Factory” is a good, clear, plain name. But some of the other names do more harm than good! Using pompous names is a BAD thing, it creates in-crowds and stops newbies. But the effects of pompous names I think are also more insiduous. They stop people from challenging the ideas, seeing them as simple and fallible things and inventing better ones. Maybe these words are too strong for the ‘design patterns’, but I think that’s what happens in psychology and most other academic fields.