Design patterns

In software engineering, a design pattern is a recommended solution to a software design problem. Design patterns generally describe how to structure our code to solve common design problems using best practices. It is important to note that a design pattern is a high-level solution; it doesn't focus on implementation details such as algorithms and data structures [GOF95, page 13], [j.mp/srcmdp]. It is up to us, as software engineers, to decide which algorithm and data structure is optimal to use for the problem we are trying to solve.

Note

If you are wondering what is the meaning of the text within [], please jump to the Conventions section of this preface for a moment to see how references are formatted in this book.

The most important part of a design pattern is probably its name. The benefit of naming all patterns is that we have, on our hands, a common vocabulary to communicate [GOF95, page 13]. Thus, if you send some code for review and your peer reviewer gives feedback mentioning "I think that you can use a Strategy here instead of ...", even if you don't know or remember what a strategy is, you can immediately look it up.

As programming languages evolve, some design patterns such as Singleton become obsolete or even antipatterns [j.mp/jalfdp], others are built in the programming language (iterator), and new patterns are born (Borg/Monostate [j.mp/amdpp], [j.mp/wikidpc]).