Question the patterns you know about
Refine those you know already
Your journey to using patterns better has already started. Reimagining the patterns you know into a problem-centred form will elevate your ability to detect new patterns. Question the patterns you already know about, both their usage and existence. Look for the way patterns were extended without fanfare, such as the routing pattern. Re-read old patterns and try to interpret them in new languages without falling into the ‘strategy is just first-class functions’ trap. Patterns are not features; you know that now. They are wisdom. There is no hidden wisdom in ‘first-class functions’.
Find different ways to classify patterns you learn about. Don’t assume they exist in one hierarchy. Look for different ways to map them against each other. Each pattern resolves a problem but may cause tension elsewhere. The downsides are often ignored or unknown, but knowing when not to use a pattern is more powerful than knowing when you can.
Learn a few more patterns and rewrite them
Learn a few more patterns from any of the published works. Thousands of
software design patterns were available at the turn of the century. There are
possibly over 10,000 now. It doesn’t matter where you find them, rewrite
them. The last
The GoF book[GoF94] contained many recurring solutions to problems but
did not introduce a pattern language. Rewriting the GoF book in a
problem-centred way would allow more people to find, extend, and use the
patterns already out there. Rewriting it as a way to migrate a codebase from
procedural to object-oriented could help migrate it to a pattern language. This
is what the book
As mentioned elsewhere, the main pattern in the GoF book was to replace procedural calls with objects. Where a function pointer or parameter would have previously dynamically defined the behaviour, many solutions in the book used an object to provide that variability. Other aspects of the GoF book could be interpreted as variations on the theme of decoupling via inheritance. In effect, the nominalisation of actions means the book reinvented callbacks as objects, meaning they had stronger guarantees in the languages available then.
Other books on design patterns also missed the language aspect. Find the problem they are trying to solve. Look at the structure of the problem and see if you can’t find the language hidden inside.