3 ms·
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".
by 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 agoI'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.