Models are used to get a better of understanding of a complex system, or to test a complex system when you can't test the real thing. A design pattern could be used to this way but they aren't. They are used as a design methodology that you are encouraged to follow.

They also aren't based on any formal theory. They are based only on the experience of the people who create them. They are almost the definition of a craft (as opposed to engineering).

In an actual Engineering discipline you would need evidence to prove that your model fits reality as opposed to just trusting the experience of a few guys who wrote a book.

From my experience design patterns are both taught and used as a starting place for solving a problem which is recognized as similar to a problem which was previously solved effectively with in the manner of the pattern. Rarely will the design pattern fit perfectly as the solution, but by recognizing and using the correct one as a starting point for many architecture related problems you can greatly reduce the work involved, in creating the solution.

They keep people from re-inventing nearly identical solutions over and over, and allow for a vocabulary which can express rather complex ideas because fellow practitioners of software engineering generally know many of the same design patterns. This saves time and reduces the opportunity for miscommunication when expressing a more complex idea (assuming the person you are talking to doesn't lie and for instance say they are familiar with the facade pattern, when they are not).

To me this is using them to both get and express a better understanding of a complex system. I am also able to understand code for new projects I am to work on much quicker when I understand the underlying design of the elements. When the elements are designed with a structure that resembles things I am familiar with this process becomes fairly easy.

I see them as things like definitions of 'Suspension Bridge', 'Victorian House', 'Tunnel', or 'Dog House'. Sure we might see a book consisting of very rudimentary definitions of structures like these as being absurd, for the corresponding type of engineer, but that is because of our familiarity with the form these structures take. That familiarity with the form is the point of design patterns in my opinion. And I believe their utility is indispensable should we want to continue building more complex structures in code.

I have no problem with design patterns as a concept. And I have no problem with design patterns being taught as the collective folk wisdom of wise sages of industry.

However, design patterns are craft, not engineering, and should be taught as vocational training--not as an academic subject.

Design patterns have no rigorous underpinnings. They have very little academic research to back up their efficacy. The only "proof" we have that the design patterns being taught are beneficial is the word of a few guys who wrote a book and the collective folk wisdom of industry.

There is nothing wrong with this, but it isn't firm foundation for an academic subject.

Again we see another Dijkstra soldier pushing the corrosive "software programming is complex" ideology. Notice how they are the same group as Martin Fowler followers.

> "They keep people from re-inventing nearly identical solutions over and over"

No, they force users to rewrite the patterns over and over again, since a pattern is an idea that a given language is not powerful enough to abstract over. Cf. opinions on the C2 wiki.

Maybe that's why you think what we do is "too complex to fully describe" - you haven't used a language that allows you to abstract at will.

OK, just cool your jets mister, everyone here is having a pretty civil conversation without you attacking people for 'pushing corrosive ideology'.

And in order to formulate that attack you pieced together quotes from two completely differently messages and people to make your 'point'.

I said they keep people from re-inventing solutions, however it was the comment you actually replied to which else claimed they were too complex.

I agree they are patterns which languages do not yet abstract over, but until languages do I think they are very useful patterns for programmers to be able to correctly recognize as they occur frequently enough that knowing the pattern saves a lot of time and work. When languages can successfully abstract over those patterns, then knowing them will be niche knowledge assuming new patterns cease to be detected by humans prior to their ability to be abstracted by a language.

> OK, just cool your jets mister, everyone here is having a pretty civil conversation without you attacking people for 'pushing corrosive ideology'.

Please.

Rhetoric = Ethos + Logos + Pathos

Unless you want to believe I chose my words while extremely angry at you personally, and unless you want everyone to never use pathos and talk like robots in perfect clauses and rebuttals connected in an acyclic directed graph, I suggested you get used to this very common rhetorical necessity.