At first, programming is just programming. You think of a thing. You make the computer do it. đ After a while, you notice that not all programming is the same. Deja vu sets in. âIâve done this before.â (Also the basis for patterns.) Empirical Software Design book series presents a series of these distinctions. (I think of them as âtwo hatsâ. Merch opportunityđ°.)
In the point about structure vs. behavior, you close with a statement that might lead some readers down an unintended path: "Separating behavior from structure changes creates value." I can see how some might interpret this as unconditional advice to separate structure from behavior; hopefully that's not the intended advice (most systems don't need to head in the direction of a bunch of structs/DTOs and util functions with no associated state).
I had to re-read that paragraph to understand that you were advising "Separating behavior _changes_ from structure changes creates value." Very different thing to separate the changes than to separate the code elements themselves.
In the point about structure vs. behavior, you close with a statement that might lead some readers down an unintended path: "Separating behavior from structure changes creates value." I can see how some might interpret this as unconditional advice to separate structure from behavior; hopefully that's not the intended advice (most systems don't need to head in the direction of a bunch of structs/DTOs and util functions with no associated state).
I had to re-read that paragraph to understand that you were advising "Separating behavior _changes_ from structure changes creates value." Very different thing to separate the changes than to separate the code elements themselves.