4 ms·

> really isn’t a design pattern per se; it’s just a formalism over the code you’d inevitably write to make such a system work. I feel like that's what all the

> really isn’t a design pattern per se; it’s just a formalism over the code you’d inevitably write to make such a system work. I feel like that's what all the original design patterns were, though, pretty much! Although maybe not "inevitable", people could write all sorts of spaghetti messes, but the original design patterns were basically formalisms of the sane ways to handle a given problem in a concise elegant way.

derefr 3y ago
"Inevitable" was the crucial distinction I was trying to make. Something isn't a design pattern if, no matter how you write it, the shape of the problem domain means that the solution looks a certain way. What you have in that case is just a formalism for describing the reflected problem domain. A design pattern is a highlighted, reified tactical choice in implementation. It's something that you, as a programmer, want to give a name to, so that you then have words to communicate the choice you made at design time, to talk about where that choice is valid/proper/important to make. These patterns can then be shared with people who haven't worked on problems where that choice is relevant before, where knowledge of the pattern then acts as a form of crystallized professional experience. Rather than looking at your individual problem, and then evaluating the pros and cons of certain designs on a case-by-case basis, you can recognize that the problem fits one or more patterns you've learned, and then merely evaluate (or rely on prior evaluations documented by others) the pros and cons of applying the pattern. When there's only one inevitable way to do things, a formalism is just there to allow software-engineering academics to model what you're doing; but you yourself, when coding, don't need those words to talk (or think!) about what you're doing. --- An analogy: A design pattern is like a martial-arts movement form. Rather than having to solve for the optimal movement to block/parry/return an attack on a case-by-case basis, learning the forms of a given art gets you to think in terms of which well-known, high-level movements would be best to apply in a given situation — which massively decreases cognitive overhead, allowing you to actually fight someone in real-time. But there's no martial-arts movement form you need to know or learn for "taking a drink of water." If there's a glass of water on a table in front of you, then there's only one natural way to pick the glass up and hold it to your mouth such that you can drink from it. "Taking a drink of water" is not a movement form, because there's no cognitive load placed on you for determining how you're going to do it. If you formalize "taking a drink of water" as a movement, that would only be for academic purposes, not practical ones.

derefr 3y ago

"Inevitable" was the crucial distinction I was trying to make. Something isn't a design pattern if, no matter how you write it, the shape of the problem domain means that the solution looks a certain way. What you have in that case is just a formalism for describing the reflected problem domain. A design pattern is a highlighted, reified tactical choice in implementation. It's something that you, as a programmer, want to give a name to, so that you then have words to communicate the choice you made at design time, to talk about where that choice is valid/proper/important to make. These patterns can then be shared with people who haven't worked on problems where that choice is relevant before, where knowledge of the pattern then acts as a form of crystallized professional experience. Rather than looking at your individual problem, and then evaluating the pros and cons of certain designs on a case-by-case basis, you can recognize that the problem fits one or more patterns you've learned, and then merely evaluate (or rely on prior evaluations documented by others) the pros and cons of applying the pattern. When there's only one inevitable way to do things, a formalism is just there to allow software-engineering academics to model what you're doing; but you yourself, when coding, don't need those words to talk (or think!) about what you're doing. --- An analogy: A design pattern is like a martial-arts movement form. Rather than having to solve for the optimal movement to block/parry/return an attack on a case-by-case basis, learning the forms of a given art gets you to think in terms of which well-known, high-level movements would be best to apply in a given situation — which massively decreases cognitive overhead, allowing you to actually fight someone in real-time. But there's no martial-arts movement form you need to know or learn for "taking a drink of water." If there's a glass of water on a table in front of you, then there's only one natural way to pick the glass up and hold it to your mouth such that you can drink from it. "Taking a drink of water" is not a movement form, because there's no cognitive load placed on you for determining how you're going to do it. If you formalize "taking a drink of water" as a movement, that would only be for academic purposes, not practical ones.