(What will happen if we use a pattern)
Testing issues: Testing wisdom that accompanies the pattern. These are hint, tricks, and tips that can make patterns, which usually depend very heavily on delegation, easier to test. They depend on a reasonable knowledge of Mock and Fake objects, which are covered in the sections on testing and test-driven development.
Cost-Benefit (gain-loss): What we get, and what we pay when we use this pattern. Understanding these issues is a key aspect of making the decision to use, or not to use a pattern. Patterns are as just valuable to us when they lead us away from themselves.
Code examples will be presented in a Java-like, C-Sharp-ish pseudo-code style that will hopefully readable by all. The purpose of both the code and UML examples is to illustrate, not to define. Patterns are not code, and are not diagrams; they are collections of forces that define the best-practices for solving a recurring problem in a given context. We provide code and UML examples because many people understand concepts better when they are accompanied by concrete examples.
Similarly, the procedural analogs are not meant to be literally applied: one would not use a Strategy pattern every time one sees a branching conditional in procedural code. The purpose of the analog is to allow us to use the part of our brains that understand procedural/algorithmic programming to suggest a possible pattern alternative, but only to ensure that we consider all of our options before making an implementation decision. The decision is, and will always be (in my opinion), a human one.
The patterns that help to define our profession are not static, but are rather a living, changing thing that we must always seek to improve and expand upon. This must be a community effort.
To this end, my organization has created this "repository". You are welcome here! Let us know your views, contribute the things you have learned, and share the wealth.