I remember reading this some time after reading "Notes on the Synthesis of Form". He's absolutely right.
“Design Patterns” Aren't (2002)
21–30 of 133 posts
Re: “Design Patterns” Aren't (2002)
#22Christopher Alexander's books:
https://archive.org/details/TheTimelessWayOfBuilding
https://archive.org/details/APatternLanguage
http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
Re: “Design Patterns” Aren't (2002)
#23Very interesting, a lot a truth, many design patterns have become useless in some languages as the language itself solves the problems.
Re: “Design Patterns” Aren't (2002)
#24Very interesting, a lot a truth, many design patterns have become useless in some languages as the language itself solves the problems.
Re: “Design Patterns” Aren't (2002)
#25The core points of this talk, as noted in the Addendum [0], is that "we need to take a fresh look at Christopher Alexander". Since that point has been established, it would make a phenomenal follow-up talk to take Alexander's book, which is from the 1970s, and begin a discourse on how his ideas can be applied to modern software engineering and architecture. While the reader takes away from the slides that Alexander h…
Or, indeed, to look at Alexander's work since this book, which has gone in a direction very similar to the programming world. In "The Nature of Order", Alexander shows how the idea of "good design" is actually best analyzed as just the output of "good process": design is about how a thing unfolds over time and becomes more itself through gradual refinements and responding to its environment.
The bigger complaint about software patterns is that, unlike Alexander's original patterns, they are merely tools useful to build any kind of program. Alexander's patterns were meant to only be useful in building humane places with humane processes. You literally could not build a mass prison with the construction methods he describes, because they aren't amenable to mass production, design from afar, or economies of scale.
Exactly the opposite is true of our usual application of "software patterns". They are often used to produce software that is inherently immoral. Alexander's patterns describe an environment of decentralization of decision-making about both architecture and the community it inhabits. Meanwhile, our "software patterns" embed a centralized power structure both in the code (architect->team lead->junior programmer) and in the world now increasingly controlled by the whims of Silicon Valley founders.
I wonder what it would look like to describe low-level primitives of computation, similar to Alexander's new low-level architectural methods, which actually made decentralization of power a reality and resisted economies of scale. They certainly wouldn't look like the Gang of Four patterns.
Re: “Design Patterns” Aren't (2002)
#26Design patterns are just a way to convey an idea. If I name something a factory, everybody knows its purpose. If I name something a prototype then people who are familiar with patterns know it will have some "clone" method. So it's a bit like UML redux. But one only need iterators if the language one uses doesn't allow you to naturally express custom iteration without requiring you to write a class or some other boilerplate.
The article demonstrates that fact pretty well.
It's also a good way to judge how practical a language is. I don't need to write iterators in a language that has generators for instance. I don't need to write factories in a language that supports closures... But then people selling all these expensive modelling tools would be out of business ...
Re: “Design Patterns” Aren't (2002)
#27I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later. For instance, MVC is a very popular design pattern. When you read code built according this pattern, even if you are not familiar with the language or framework, you know what kind of thing to expect to find in different parts of the program. They can also be useful in a context where not eve…
That's exactly right. The GoF patterns were identified from experience and then formalized, not created from whole cloth. Programmers that don't know anything about design patterns use many of them, often without realizing they are doing it.
The GoF patterns give everyone a common vocabulary to reason about the patterns.
Re: “Design Patterns” Aren't (2002)
#28I like his point about Alexander going after delegation of design decisions, though I don't necessarily think that's the only point he was driving at. From "The Timeless Way of Building" I got that he's also driving at this:
1. Modern (not necessarily just modernist) architects are generally terrible at achieving what Alexander refers to as "living space" because they're solving for the wrong things.
2. Small-scale patterns and large-scale patterns can constructively or destructively interfere with each other from urban planning right down to construction details of a room.
3. If you've really mastered design, you can leave behind the pattern language and cookie-cutter implementations: your solutions will organically develop with these large-scale/small-scale synergies.
I'd suggest that GoF is a little closer to Alexander in these respects than the presenter gives credit for, particularly for point #3. The book studiously makes the point that its implementation of these patterns is not meant to be the only way to implement them. It also makes no attempt to be an exhaustive catalog. The fact that some of these patterns have standard and different implementations in other languages (e.g. iterator method hooks and generators in Python) doesn't necessarily mean that the pattern itself is useless outside of its OOP niche.
I'm glad WikiWikiWeb is back up so we can debate all of this on the one true forum for debating design patterns. :-)
Re: “Design Patterns” Aren't (2002)
#29Very interesting, a lot a truth, many design patterns have become useless in some languages as the language itself solves the problems.
hey man can u explain to me what is this place (website)
Re: “Design Patterns” Aren't (2002)
#30The thing very few people seem to get about Design Patterns (in the gang-of-four sense): they are not a Good Thing, desirable and worthy of study in and of themselves. They are a necessary evil to compensate for fundamental deficiencies in C-like programming languages.