3 ms·
Examples of that were common in 2000s poor Object Oriented Programming introductory material, do people still advise that kind of design? There were people who
by forgetfulness 4y ago
Examples of that were common in 2000s poor Object Oriented Programming introductory material, do people still advise that kind of design?
There were people who abhorred the sight of non-stateful code, there was little opportunity to fiddle with objects in it, not realizing that they just made their and everyone else's job harder with more moving parts, a concept that, despite being very easy to understand and with analogues to physical machines, was lost on many programmers.
- johannes1234321 4y ago> do people still advise that kind of design? It is a constant discussion. You can always find examples of long functions with lots of state which is hard to follow and then there are always examples of code where people went too short. And then there are always people taking any of those examples and showing why they were wrong. I myself like going to the extremes for fun/toy/throwaway projects (not only on these but also with rules like "no `if`" or "no raw `for` loop" etc) to try out all the different alternatives and then resetting my default based on cases where it went well and where it went bad. No such rule is always right, but most hmstem from being exposed to too much of one extreme.
- layer8 4y agoThe correct way to do this, if it really is a significant simplification, is to factor out the minimal relevant code into a private helper class (or struct) that you instantiate anew for each computation. It then functions like a stack frame you can pass around and share between functions/methods, within private boundaries.