Design Patterns in Action

The canonical reference in this subject, as written by the GoF, introduces 23 design patterns, each falling under one of the creational, structural, and behavioral categories. There are even more patterns or variations of existing ones, but rather than learning all of these patterns by heart, we should focus on keeping two things in mind:

• Some of the patterns are invisible in Python, and we are likely to use them without even noticing.

• Not all patterns are equally as common; some of them are tremendously useful, and so they are found very frequently, while others are for more specific cases.

We'll look at the most common patterns, those that are most likely to emerge from our design. Note the use of the word emerge here. We should not force the application of a design pattern to the solution we are building, but rather evolve, refactor, and improve our solution until a pattern emerges.

Design patterns are therefore not invented but discovered. When a situation that occurs repeatedly in our code reveals itself, the general and more abstract layout of classes, objects, and related components appears under a name by which we identify a pattern.

The name of a design pattern wraps up a lot of concepts. This is probably the best thing about design patterns; they provide a language. Through design patterns, it's easier to communicate design ideas effectively. When two or more software engineers share the same vocabulary, and one of them mentions the strategy, the rest of the software engineers in the room can immediately think about all the classes, how they would be related, what their mechanics would be, and so on, without having to repeat this explanation.