Patterns is not a new buzz or anything, actually patterns, the use hereof and definitions started in 1994 when the book “Design Patterns” was released by the gang of four. Since then there have been uncountable books published on the subject of patterns. Some of the more noticeable and most frequently mentioned is “Enterprise Integration Patterns”, “Patterns of Enterprise Application Architecture” and lesser known “Patterns in Java” and similar “Patterns in Objective-C”. All good books and definitely worth spending time browsing through.
When saying browsing through, then personally I never found it especially worthwhile to read any book on patterns from start to end. Mostly due to the fact, that I simply cannot remember all the patterns described after reading the book. When browsing, through, and reading the introduction to different patterns – you can pick up the essence and if a patterns relates to something you have worked on, you get a standard terminology useful to describe for others what specific area of the code is accomplishing.
Over the years I have witness a number of projects where the engineering teams adopt what I prefer to refer to as “Pattern Driven Development”. All major pieces of the code ends being structured around specific patterns, to the extent that you can actually recognize the code in the systems from the books in which a particularly pattern was found. Moreover, different engineers read different patterns books, which means that you can find same patterns implemented slightly different in different sections of the system.
The latter, as anyone can envision, leads to a fragmented and confusing code base, with a non-cohesive implementation of code solving similar problems sometimes even same problem, being contradictory to the fundamental idea of patterns, being providing an uniform understanding and terminology to use when discussing and addressing specific problems.
To me the real value of patterns is not the example code, but the problem a given pattern solves and the terminology which can be seen as constituting a protocol between developers when interacting about a specific problem to be solved. To simply use the examples provided in your own code is, in my view, not a good plan.
Claus Jepsen 