3 ms·

I have read Christopher Alexander’s bibliography and also had this impression that software people got it “wrong“. The patterns on GoF aren’t really at the same

I have read Christopher Alexander’s bibliography and also had this impression that software people got it “wrong“. The patterns on GoF aren’t really at the same level - an “Iterator” is too low-level and not at all the level at which you would be discussing architecture with the end-users, which is the point of C.A. They focused on pattern “reuse” because that’s what the industry and OOP obsessed about - in the end reuse happens at package-level, so the industry missed the mark. In fact, it surprises me the focus on “A Pattern Language” at all when the “Notes on the Synthesis of Form” is a much relevant book on the topic of gathering requirements, prototyping and designing solutions. Anyway, I recommend going straight to the source and reading Christopher Alexander’s work as it’s very relevant for anyone designing solutions of any form.

HelloNurse 6y ago
The GoF design patterns are low level, as noted in earlier comments, with respect to the standard of using them to communicate between software designers and software users, but also sufficiently high level to be nontrivial techniques in a certain class of OOP languages (Smalltalk, old C++, Java). They deserve an explanation, help the programmer to reason about architecture "from the bottom" and explain technical issues concisely, and serve as examples of more general good design principles. They have also proved to be a positive driving force in the evolution of programming languages and libraries. More "important" design patterns, such as organizing an enterprise application around executing transactions against a database or stipulating whether a soft realtime application like a videogame should lag or skip frames when overloaded, are usually too abstract and complex to give universal advice about.

HelloNurse 6y ago

The GoF design patterns are low level, as noted in earlier comments, with respect to the standard of using them to communicate between software designers and software users, but also sufficiently high level to be nontrivial techniques in a certain class of OOP languages (Smalltalk, old C++, Java). They deserve an explanation, help the programmer to reason about architecture "from the bottom" and explain technical issues concisely, and serve as examples of more general good design principles. They have also proved to be a positive driving force in the evolution of programming languages and libraries. More "important" design patterns, such as organizing an enterprise application around executing transactions against a database or stipulating whether a soft realtime application like a videogame should lag or skip frames when overloaded, are usually too abstract and complex to give universal advice about.