I think Design Patterns is often painfully misunderstood and misconstrued. My idea of using the factory pattern, for example, is not to write a MarriageFactory

I think Design Patterns is often painfully misunderstood and misconstrued. My idea of using the factory pattern, for example, is not to write a MarriageFactory class, but to write a Celebrant class, and we may recognise that it embodies the factory pattern if that is helpful to the comprehension or authoring of the code. And so it goes with the others, many of which I use extensively in my own work, but at most there's a comment at the top saying, for example "this business rules structure is in the chain-of-responsibility pattern". That is the material use of patterns, they are not abstract frameworks. Naming things makes a difference: encouraging a taxonomy of purpose, rather than of form, goes a long way to re-orienting a programmer towards problem-solving with concretions rather than abstractions. As a consequence, Design Patterns, along with Refactoring and PoEAA, continues to serve as one my most-thumbed indexes of solution ideas.