4 ms·
I’ve read the original and was underwhelmed from a software epiphany standpoint. Design patterns are just names for deliberate design decisions, so you can comm
by thom 4y ago
I’ve read the original and was underwhelmed from a software epiphany standpoint. Design patterns are just names for deliberate design decisions, so you can communicate them to others who can then deliberately make those decisions themselves. Half the industry still seems to think the GoF book is about C++ not having first class functions.
- hinkley 4y agoThe problem is that they are milquetoast. They are “design decisions” in the same way that white space is technically code style but really distracts from the real elements of style like structure and meaning (don’t create three meanings for the same word, for example). Architecture is much bigger than making sure the doors open the correct direction.
- thom 4y agoWell, there are many collections of patterns, GoF doesn't claim to be exhaustive. Enterprise Integration Patterns is more high level, for example. But for everyone who hand waves away something like the Strategy pattern as trivial, I have to work with a dozen libraries which accept a massive dictionary of static options to configure their behaviour instead of allowing me to choose an arbitrary, dynamic policy at runtime. I don't think that's a conscious design decision on behalf of most API developers. I suspect it's because the industry largely received the original GoF book as a bunch of cut and pasteable code and later rejected it as symptomatic of Java-esque OO excess. We could instead have received it as a network of signposts telling us what's possible, when and why. Not earth-shattering stuff (neither is Christopher Alexander's original) but useful nonetheless.