5 ms·

Nah, design patterns are mostly communication tools. When you name something "factory", when some doc mentions "dependency injection", when you import a "regis

Nah, design patterns are mostly communication tools. 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. 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. 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. 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. 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. That's how it works, not the other way around. It's formalization of real life, not theory to apply.

rileymat2 5y ago
> 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. This is an interesting analogy maybe someone who knows more about chess can correct me, but don’t chess masters have elaborate memorized openings and end games where they do decide to use “the indian defense” then go on autopilot until someone deviates from the common lines?
- BiteCode_dev 5y ago
  The idea is that they won't tell themself, "I'm going to use the indian defense". Just like I won't tell myself "I'm going to apply the strategy pattern here". We just see the situation, and if it calls from a solution from the banks of solutions we have encountered in the past, we see if it fits, we try to apply it if it does (tailoring may be necessary). Then the commentator later may say "oh, he decided to use Y". But that's for the benefits of the people watching.
  - setr 5y ago
    I'm largely agreed with this, but to add on: if you consider the idea source -- Alexander's A Pattern Language -- the notion of a pattern is a more useful than that; it is both a communication tool, as well as the realization that the problem (in his case, buildings) can be subdivided into smaller parts, and at a certain level, these parts fall into common repeating forms (patterns). You can thus mostly initialize the design by simply composing patterns together. The key that typically gets lost in GoF pattern discussions is that it doesn't end there. Once the patterns are decided, you need to account for the non-standard details of the problem at hand -- e.g. the house is partly on a hill. The hill raises the height of the door. The door had a relationship with the window -- it's no longer aligned, and will have to be modified to fit. With the shift of the window, the mirrors need to change.. and with the mirrors, the door. Eventually these changes will stabilize, producing an equilibrium (TB: he declares that equilibrium to be "beauty", and a feature that everyone can innately detect, though they may not know how to reach it... this corresponds strongly to "code smell" or "elegance" in programming) So the elements of the home starts as patterns, but they're also in a fluid state, and the effects of reality will trigger a feedback loop, creating continuous design reflows, until the whole thing reaches an equilibrium (and you can now build the house). He then goes on to note that the home exists in a continuously fluid state (as it's used and changed by inhabitants), constantly deviating from that equilibrium, and being brought back into that state. So the most beautiful homes are those not designed into a harmonious state, but maintained in a harmonious state -- I particularly like the correspondence to programming here.
- Jensson 5y ago
  The equivalent of a standard chess opening would be a function call or some form of template in software engineering.
- School-Cotton 5y ago
  Yes, but even after the opening lines are exhausted, a huge part of expert chess play is just intuition and choosing which moves “look right”, rather than conscious thought and calculation (though that too has its place).

rileymat2 5y ago

> 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. This is an interesting analogy maybe someone who knows more about chess can correct me, but don’t chess masters have elaborate memorized openings and end games where they do decide to use “the indian defense” then go on autopilot until someone deviates from the common lines?

BiteCode_dev 5y ago
The idea is that they won't tell themself, "I'm going to use the indian defense". Just like I won't tell myself "I'm going to apply the strategy pattern here". We just see the situation, and if it calls from a solution from the banks of solutions we have encountered in the past, we see if it fits, we try to apply it if it does (tailoring may be necessary). Then the commentator later may say "oh, he decided to use Y". But that's for the benefits of the people watching.
- setr 5y ago
  I'm largely agreed with this, but to add on: if you consider the idea source -- Alexander's A Pattern Language -- the notion of a pattern is a more useful than that; it is both a communication tool, as well as the realization that the problem (in his case, buildings) can be subdivided into smaller parts, and at a certain level, these parts fall into common repeating forms (patterns). You can thus mostly initialize the design by simply composing patterns together. The key that typically gets lost in GoF pattern discussions is that it doesn't end there. Once the patterns are decided, you need to account for the non-standard details of the problem at hand -- e.g. the house is partly on a hill. The hill raises the height of the door. The door had a relationship with the window -- it's no longer aligned, and will have to be modified to fit. With the shift of the window, the mirrors need to change.. and with the mirrors, the door. Eventually these changes will stabilize, producing an equilibrium (TB: he declares that equilibrium to be "beauty", and a feature that everyone can innately detect, though they may not know how to reach it... this corresponds strongly to "code smell" or "elegance" in programming) So the elements of the home starts as patterns, but they're also in a fluid state, and the effects of reality will trigger a feedback loop, creating continuous design reflows, until the whole thing reaches an equilibrium (and you can now build the house). He then goes on to note that the home exists in a continuously fluid state (as it's used and changed by inhabitants), constantly deviating from that equilibrium, and being brought back into that state. So the most beautiful homes are those not designed into a harmonious state, but maintained in a harmonious state -- I particularly like the correspondence to programming here.
Jensson 5y ago
The equivalent of a standard chess opening would be a function call or some form of template in software engineering.
School-Cotton 5y ago
Yes, but even after the opening lines are exhausted, a huge part of expert chess play is just intuition and choosing which moves “look right”, rather than conscious thought and calculation (though that too has its place).