Nah, design patterns are mostly communication tools.<p>When you name something "factory", when some doc mentions "dependency injection", when you import a "register", when you talk with a colleague about a "decodator", if you know the name, you already know what it does, and what the API will probably look like.<p>I say probably, because we don't have a format definition of all design patterns, nor are they all recognized as such. For for the ones that are and we do, we don't all agree. Not to mention you must adapt them to problems and languages.<p>So sure, when you code and you encounter a problem, you may use a design pattern. But you don't explicitly do so. Just like a chess master doesn't chose a move by thinking "I'm going to use x", they just decide on it, and also adapt it to the situation.<p>I never think about design patterns when I code, only when I name the code, I write the doc, and talk about it. When I communicate.<p>If you read a book about design patterns, they will make no sense to you. You will probably misuse them. But if you look at real life source codes from other devs, or yours again and again, you realize some problems come back often, and a lot of people use similar solutions. Then you look it up: bingo, it has a name.<p>That's how it works, not the other way around. It's formalization of real life, not theory to apply.