Problem centric
I have enjoyed reading GoF book not because of the, as some might put it, twenty three cheap design tricks enlisted, rather as examples of recurring problems paired with some elegant solutions. Now in retrospect I might argue that naming the book ‘Design Problems, Treatise of Solutions to Recurring Difficulties in Object-Oriented Software’ would have caused less havoc. To few patterns that I see in code are actually motivated by a real need, rather than mere desire to apply something from the catalog. Or at least that is how I feel: being problem rather than solution centric does pay off.
Problems pretty much appear in the same form regardless of the language, whilst solutions are more different than one would expect. Even the UML models of generalized structure of the pattern can be different in some languages like Ruby (although the very use of UML is questionable with such a dynamic Duck Typed language). Take for example the extremely complex Visitor pattern, intended to extend the operation set applicable on an object structure. In Ruby where classes are open for extension implementing a generalized Visitor structure becomes quite useless.
