I agree with x=10.0 etc, but not all languages have named arguments :-) This is but one way to simulate them. Note that Fowler was using what appears to be a Ja

I agree with x=10.0 etc, but not all languages have named arguments :-) This is but one way to simulate them. Note that Fowler was using what appears to be a Java factory. Breaking up the large function into smaller functions is ultimately the goal, yes. In my experience, researchers without software engineering backgrounds are very against breaking up an algorithm this way. For the most part, they think that it makes it less readable, because now their algorithm isn't in a single block like it is in the textbook. (The other argument they often give is that they fear breaking it up will impact performance). It's certainly possible to use structured programming here and instead encapsulate the state into a little struct that is passed around; this was the way things were done in C before C++ came along and created classes, and there will always be people who think this to be the superior approach :-) A set of isolated functions can get hairy if you're not able to hide the helpers away from the entry points; not all functions are necessarily generic and reusable elsewhere (if you end up with it that way for your specific application, great!). Encapsulation into a class or namespace can help with that. I'm not sure I agree that isolated functions protects us against code rot more so than with classes. There is always refactoring to consider in both cases. In one camp, you have immutable data classes with functions operating on those data classes and possibly returning another data class (functional programming). In another camp, you encapsulate a reasonable amount of behavior into a class whose methods may mutate the class data (OOP). Both have their strengths.