I'm Sick Of GOF Design Patterns

> 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 -- 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.

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

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.

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.

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.