[setr]

Design patterns are intended to be a description of patterns found in the wild — that is, it’s descriptive, not prescriptive.

Once distilled to their essence, and documented, and named, it becomes possible to efficiently talk about it and reference it.

They are natural things, to be found in wild codebases, that are documented and named here. That they get used and abused, or people come up with terrible names (ClassFactoryFactory) is more a lack of taste than anything — but knowing that such patterns exist and their utility is a requirement of any tradesman seeking to move above novice. The name isn’t as much needed, but it makes it trivial to google.

But again, these are patterns found in the wild — it intends to document problems & solutions that programmers have encountered, and it’s a pattern because it comes up often enough — which implies that you will likely encounter similar problems and (perhaps discovered on your own) implement similar solutions.

[setr]

Also an addendum — design patterns originate from Christopher Alexander, who was discussing the same fundamental idea but applied to natural architecture (that is, not bounded by strict regulations, laws, complex requirements, etc) in various populations; he noted that communities tend towards certain patterns and trends that work, and apply them repeatedly. But the key difference between Alexander’s pattern architecture and say, a McMansion, is the pattern only acts as a start; depending on its context (including other patterns used) the pattern is modified to fit more appropriately. And everything else is modified in reaction to that.

So the movement of a door changes how the window should be placed, which changes the best position of the sofa, which changes the ideal spot for the door, and so on. So it’s a feedback loop, approaching some optimal state where everything is in harmony with everything else (a state he calls “beautiful”, an inherent property all people recognize even if they cannot produce it themselves) — but because people live in the home, and use it and modify it and change through generations, that harmony is a moving goalpost, always sought but only possible to achieve once abandoned.

The analogy to software development is easy to make, but the key point here is that in usage, patterns are not the end but rather the beginning of a design — they can and should be modified to fit, until it is beautiful

[ritchiea]

This is a brilliant distinction, that design pattern are meant to be descriptive rather than prescriptive. Because the problems I tend to see in the wild are when developers treat design patterns as prescriptive.