The more patterns developers know, the most efficient they become within a team: it only takes one or two words (the pattern name) to communicate a design decision or proposal, instead of 10 mn of explanations. Communication also gets much more accurate and to-the-point (or less fuzzy).
Because patterns often form a pattern language, not only they offer a standard vocabulary but they also help structuring the mind by their relationships: patterns can be related as exclusive alternatives, or rather often-go-together, which is useful.
Patterns are not always supposed to be “tricks” to learn, or extra complication to introduce to a design; indeed even obvious and uninteresting pattern are worth reading in books, just for the social advantage of being able to reference them. Going further, sometime you can just go to the book to find out which is the pattern that you just did without knowing its name…
![]() |
|
||||||||||
![]() |
|
||||||||||
![]() |
|
||||||||||
![]() |
|
||||||||||
![]() |
|
||||||||||
![]() |
|
||||||||||
![]() |
|
||||||||||










[...] for almost two decades to inventory as many such arrangements as they could find, resulting into many books and publications in every [...]
[...] Essential books on software patterns, posted some time ago on this blog [...]