I learned a lot from reading the GOF book two or three years into my programming career. I think like most people, I'd already invented a few of its patterns, like pluggable Strategies, but it was great to have shared names for things.

On the other hand, I interviewed a while back and was talking about a web sockets project where my Javascript received a callback when a message arrived. "Did you think of that in terms of Design Patterns?" they asked. "Not really, callbacks are pretty common in Javascript." They really didn't like that answer. If I could think faster on my feet, I'd have whipped out that quote from Peter Norvig: "Design patterns are bug reports against your programming language."

This person sounds super jaded. Like they didn't get a job because they didn't know about some pattern they were asked about.

The thing about the GOF book is that it gives you a great foundation for designing great software. No, they aren't the only patterns out there, but you are going to find at least some of them in any well designed system. You will also see a lot of code that is clearly based on a GOF pattern, but evolved from that to solve a specific problem.

For instance, you can't get a web job these days without being familiar with MVC. And really, you should know what component modern day web frameworks are missing (an observer). You will probably use some rendition of the chain of command at some point in your career. Then you have the proxy pattern, bridge pattern, adapter pattern which are all popular as well.

So sure, hate on GOF. But you're completely missing something if you do, and expressing such distaste for it makes you look bad (imo). GOF doesn't take away the creative aspect of programming, it actually facilitates it by giving you a solid foundation of which to work. So while some will perform a piece of sheet music, others will use the sheet music as inspiration to create something new and beautiful.

> Yet people insist on you naming a design pattern in interviews, like it's a secret handshake, or asking a carpenter if they know any kinds of wood. What does it prove? Nothing.

Looking at someone's code is more useful than asking if they know patterns. But some knowledge of patterns is a good thing IMHO.

For example, if I can point at some of my code and say "Yeah, that's kind of like a factory" and know I'm understood by my teammate, then that's a good thing.

One goal of the design patterns movement was to introduce a terminology that could be shared and understood. I think they succeeded to some degree, because employers are looking for familiarity with this terminology. Why is it such a PITA?

> Programming isn't paint by number, every day you make decisions on what to write and how to design or structure the code in a continuous basis.

But wouldn't it be quite cool if you could check your thinking against other peoples successes and failures? Patterns simply catalogue problem/solution, I don't think you're supposed to implement them in a paint by numbers fashion.

The right answer to the Patterns interview question is, "Whenever I see a pattern, I abstract it away."

Obligatory link:

16 out of 23 patterns were found by Peter Norvig to be simpler or invisible in Lisp or Dylan:

http://www.norvig.com/design-patterns/

I had just finished undergrad computer engineering when the GoF book was published and it was a total revelation at the time. But as the author says, good ideas can be made terrible by too much slavish devotion and not enough thinking.

I think the key usefulness of books like "Design Patterns" is to create a common language. Now, when I say "this is an observer" people instantly know it subscribes to an "observable" which notifies its observers by calling their callbacks.

Now... What I am sick of is people misapplying those patterns in situations and languages they really shouldn't.

I always viewed design patterns as a communication tool between programmers. Saying

  $('.button .link .pulldown')
     .addClass('active')
     .on('hover', highlight)
     .on('click', doSomething);

is quite a mouthful. But if everyone's familiar with design patterns, then you can just say "Oh, it's a Builder pattern" and everybody knows what you're talking about. Same goes for many, many other situations; familiarity with MVC will go a long way towards understanding angular.js, and familiarity with Chain of Responsibility will teach you about WSGI or Django Middleware, or the State pattern will help you understand trampolines in interpreter implementation.

The adage "those who don't know history are doomed to repeat it" comes to mind when I read this article.

If you simply write off the GoF patterns then you're likely to spend a lot of time creating inferior solutions to common problems. You are less likely to recognize a common problem when you see one. At the same time, people who just see the GoF patterns as some sort of bible will implement things in a ridiculously complicated way because they're trying to use as many patterns as possible.

Basically they're just tools to have in your tool chest. You have to learn how and when to use them.

2005 called, it wants its strawman argument about 90s object oriented design books back.

While we're revisiting the classics: I'm Sick Of XML Configuration Files! I'm Sick of Static Typing! I'm Sick of Exceptions!

> Yet people insist on you naming a design pattern in interviews, like it's a secret handshake, or asking a carpenter if they know any kinds of wood. What does it prove?

It proves you can communicate succinctly with other developers. I can't count the number of times I've had a coworker laboriously explain some design they "invented" only to reach the end and realize they just described an observer, or command, etc.

Sure, I get sad when people overuse design patterns too, but I find them incredibly helpful as a communication tool.

that's as good as saying "i'm sick of arcs, square windows, rafter roofs and linked lists". of course patterns aren't the end-all-be-all of software development. but it's the trait of a good craftsman and engineer to know what patterns exist and how to use them.

Sadly, and in that I agree with the author, people in interviews only ask for knowledge of patterns, not when and when not to use them.

in that sense, the title better were: "I'm sick of people thinking of patterns in an idiotic fashion", avoiding creativity at all cost". But then, that's just complaining about the single-mindedness of less experienced colleagues.

The patterns themselves and knowing how to use them I still consider a valuable asset and in parts, the author says that.

But beyond that, the value of patterns is that you can easily communicate with other developers about architectural decisions. And communication is 80% of software development in a team.

"What do you think about Design Patterns ?" is actually a really interesting question to ask during an interview.

I don't know that you understand the true value in patterns. Take for instance this series of numbers. 1,1,2,3,5,8... I bet you can look at it and say hey I recognize that pattern, 13 will come next because its the fibonacci sequence. Immediately, you can look at 5 and 8 add them together and know what comes next. You don't have to confirm the math that lead up to 5 or 8. You know because you understand the patter.

Patterns in software mean the same thing. If I can recognize the pattern through reading code, UML, or by being told with jargon, I am going to save time and energy.

I am going to assume you are not a musician or music theorist or something along those lines. Mainly because music is patterns.

MENSA describes intelligence as the ability to recognize patterns. (Couldn't find my source on this.)

But lastly, GOF didn't tell people that their patterns are a means to an end, they are a starting place.

I'm tired of design patterns, too. One of my favorite quotations these days is Brendan Eich's paraphrasing of a sentiment attributed to Peter Norvig: “Design patterns are bug reports against your programming language”.

That said, if you can write a rant of this length on the topic without once mentioning how they facilitate higher-bandwidth communication between team members, you're missing something.

Asking about design patterns in an interview is not a secret handshake. Instead, you are being tested to see whether you're just bringing your own programming talents in isolation, or whether you're also bringing along the force-multiplier of communication.

In my interview revenge fantasy I imagine turning the tables on the interviewer:

"Before I tell you what I know about design patterns, let me ask you a question. From speaking with you, I can tell that you are articulate and have a good command of the English language, in other words, you're a good communicator.

Now, if I asked you to give me a sentence containing a gerund in a preposition phrase could you? Probably not, even though you probably don't go a day without writing such a sentence. Could I assume that because you aren't familiar with the terms in the above question that you probably aren't a good communicator?"

I somewhat agrees with the author. But I think GOF Design Patterns is only ONE step in the right direction and it is time to move beyond that.

It is because of the GOF Design Patterns that we started to talk about anti-patterns. In my opinion, learning about the anti-patterns maybe more important than learning about patterns.

The author's analogy with Mozart's music is curious. Mozart's compositions are closer to the classical forms of a symphony, concerto, etc. than other well known composers who came later. He didn't slavishly follow some rules, but other composers broke way more rules than he did.

Edit: Grammar

I think what you're trying to say is that you're sick of people misusing or otherwise applying GOF patterns without thinking about them. Being 'sick of GOF patterns' is something entirely different.

I've always taken these "design patterns" to be a Shibboleth of the bottom 80-ish percent of programmers.

The mediocrities can't handle math. If they dig deep enough into any technical area, they get confused and insecure and pissed-off. Design patterns is the Revenge of the Not-Nerds. It's to use the language of the business to turn the tables and make the actually competent feel queasy and unsure of themselves in the (artificially stupid yet complex) environment. It ends up reinstating a mediocrity-protecting connections- or seniority-powered system because no individual can get anything done.

I call the programmers who like that nonsense "math haters". (Rhymes with "death eaters".) Instead of y = sin a*x, which is "too mathematical", it's a Vibrator object with an .apply(double x) method that returns a double. That class of functions (parameterized by a) is a VibratorFactory. But since there can only be one, why not seem extra business savvy and call it a VibratorFactorySingleton. I'm going to throw in Proxy and Abstract and Visitor in there too, not because I know what they mean in this context (I don't) but because no one else does either so I can get away with it. It's an AbstractVibratorFactoryProxyVisitorSingletonFactory.

All because I needed to use a simple trig function. But (to the math haters) trig functions are scary!

So much of this "enterprise-y" nonsense is there not just to dumb down, but to smart-out (as in, drive the smart people out of) programming. It serves the interests of characters like Twitter's PHP CEO (obviously fictional, but people like him exist) who seek to commoditize programming at all costs.

For more on this: http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol...

Thank you.

This explains thoroughly what is wrong with design patterns ala GOF. It's not that particular frequent patterns in particular languages or enumerating them in academic fashion is wrong. It becomes wrong when sophistry of these band-aids to language flaws are raised as somehow being really important, when actually they are just reactions to accidental complexity. It often creates unnecessary complexity to description of systems and cargocult overengineering.

I would claim that it's much more beneficial for budging engineers to program something they have not programmed before (like a space invaders clone or a scheme interpreter) than to remember each GOF pattern.

And, since these band-aids are unnecessary in several languages, it would be much more fruitful to learn one of these languages rather than memorize some band-aid.

The reason the patterns are common is that they are pretty much obvious after you understand the low-level language and you are familiar with some higher level language.

It's nice to be able to give things names, but, being able to name a bird does not mean you know anything about it's important characteristics. Or, to misquote Feynman, "GOF design patterns are pretty much as important to software engineering as ornithology is to birds".

Also, if you read Christopher Alexander's work, I would claim that GOF patterns are not patterns in the sense Alexander uses.

I've seen quite a bit of damage done by GOF patterns. Simple code bases become more complex due to an implementation of some GOF pattern because that's "the modern way to do it by the book".

I would claim that it's important to first figure out a most simple way to do something, and if it fits into some GOF category then fine, you can identify it and move on.

While that paper is specifically addressed to "Dynamic Languages", I suspect you'd find similar things with modern static functional languages with more robust type systems (Haskell, particularly.)

I actually found that comparison to be a great example of why design patterns are useful. By naming the pattern, Norvig was able to instantly list 16 ways in which dynamic languages solve real-world problems.

> that's as good as saying "i'm sick of arcs, square windows, rafter roofs and linked lists".

Well, no -- except for the last, which we'll come back to -- because software isn't the same thing as physical architecture. The nature of software is that components can be and should be reusable, so if you have to rebuild the same thing from a complex "pattern" (more than a simple parameterized constructor or the equivalent) each time you use it, it means that the tool (programming language) you are using has a failure of reusability. With physical architecture, you obviously need to build a new copy every time you need one -- windows are fundamentally not reusable.

Now, for linked lists, yeah, it would be silly to be sick of linked lists as a concept when building software.

OTOH, you can legitimately be sick of having to build a struct with a data member and a next pointer and all the associated manipulation functions every time you need a linked list of <new data type> -- that is, sick of linked lists as a GOF-style Design Pattern -- rather than being able to (if you want to be exceptionally explicit about naming a type for the list) doing something like:

  type newDataTypeList = [NewDataType]

The better your language is, the less you have books of "Design Patterns" with implementation recipes, and the more you have code libraries where the documentation of the "pattern" covers effective use, rather than implementation.

What an obscure load of tosh. I might as well say that all the maths-nerds don't really know how to program because they don't understand design patterns properly, as evidenced by them hating on it all the time.

But of course, I wouldn't say that because I have absolutely no evidence and it would be based purely on my close-mindedness and preconceptions. (I also wouldn't say it because I have no hatred towards "maths-nerds" !)

And also - when has a pattern ever been used to abstract away a maths problem? I certainly haven't seen it!

Understanding patterns, but more importantly, design principles, help when writing code because of the limitations of the language (any language) in properly describing the problem domain. If those principles lead to the creation of patterns which are then given names and taught to the masses, I cannot understand how learning about them would make someone a worse programmer.

That's well and good, but quite a lot of business value can be created using sub-elite programmers.

The problem with not having a good common vocabulary is that it makes it harder and harder to ever have proper engineering in software.

That said, your example of not being able to use trig is flat out unacceptable--that's things taken much, much too far. Even an average programmer shouldn't be afraid of basic trig.

That should be ".apply(Angle x)", not ".apply(double x)". It's not properly enterprise-y if you can actually see a primitive type anywhere.

The "enterprise-y" garbage you note has almost nothing to do with the mathematical competence of programmers who implement it.

You write as though programming is an exercise in mathematics. It's not, in general. There are specific problems where mathematics is actually a component of the problem/solution space, e.g. mathematical research, scientific computing, in which programming is the form of the solution to the math problem (analogous to, e.g. "express your answer using set notation", except in this case it's "express your answer in the form of a computer program"). Mathematics may underpin some of programming, and most often in some areas of computer science, but the vast majority of software development has very little to do with math.

Why bring a thought-up ridiculous example when you can post a link to the infamous AbstractSingletonProxyFactoryBean?

Anyway, patterns aren't some "evil plot" by "math haters", they are simply recipes that solve recurring problems. They weren't really "invented" by GoF or anyone else, these things tend to emerge when a lot of people people do a lot of software engineering projects.

Also, you're wrong if you seriously think that the majority of software engineers needs to know trigonometry (or any kind of math at all) to do their jobs.

The only thing worse than "enterprise-y" nonsense is blogs of lame psychoanalysis of characters from a fictional office sitcom complimented with its own language-stan to throw off outsiders, all in the service of some Nazi-like narcissitic crusade of "smart" vs "idiot".

But see, even math can be misused in the same way. Instead of y = sin a * x, it becomes both a functor and a monad. See, that's even more mathematical!

Those who have only a superficial understanding can (and will) mis-apply anything. That includes all of us, at some time in our careers. Those you dismiss as the "bottom 80" include anyone starting to learn anything. Some of them will grow to know how to use the tools well; some may never do so. But don't condemn the entire tool because you've seen it used badly.

More: You seem to be condemning everyone who doesn't program your way as being stupider than you. That is far more likely to be arrogance than to be the truth.