> Design patterns suffer because in most explanations the context is completely missing.

"most explanations"? Most crappy explanations on the web and in introductory courses perhaps.

The original GoF Design Patterns book and all of the Pattern Languages of Program Design books that followed it define and adhere to a pattern (form, template) for how to document design patterns. The main elements of this form are (GoF, p.3):

1. The *pattern name* ...

2. The *problem* describes when to apply the pattern. It explains the problem and its context [emphasis mine]. ...

3. The *solution* ...

4. The *consequences* are the results and trade-offs of applying the pattern. ...

I am guessing this form comes from Christopher Alexander, but I don't have a copy of A Timeless Way of Building at hand.

▲

galaxyLogic 4 days ago | parent [-]

Don't overlook the "Forces". While "Problem" explains WHY you might need the specific pattern in question, the "forces" explain why some trivial solutions are not very good solutions, because you have to take into account the constraints, the assumptions about the context, why the problem is actually a problem.

MVC is a great, even proverbial pattern, but I don't recall having seen it presentewd in the "Patterns Format" anywhere. Such a presentation would make it easier to understand no doubt.

▲

Kerrick 4 days ago | parent [-]

It is presented in the patterns format in at least these places:

- Pages 125–143 of Pattern-Oriented Software Architecture (1996) by Buschmann et al. ISBN 978-0471958697.

- Pages 330–332 of Patterns of Enterprise Application Architecture (2003) by Martin Fowler. ISBN 978-0321127426.

	▲	RossBencina a day ago \| parent [-]
		I have those books. I can confirm that your citations are correct. That said, Fowler's presentation is brief and doesn't really pass as "pattern form" in my view. POSA has its own slightly different pattern form Context/Problem/Solution/Structure/Dynamics/Implementation/Variants/Known Uses/Consequences:benefits/Consequences:liabilities/Credits(Trygve Reenskaug)