You need to explain #3 more. The transformation is usually far deeper than just “creating multiple functions”. You have to rework all your type signatures, intermediate data structures, and higher-order methods, too.
Also, unrolling complex logic into a huge chain of single-use methods with ever-larger numbers of parameters (as various steps are validated) is something I’d consider a code smell, not an improvement, in most cases.
I was peaking more to breaking up the implementation. The public functions need not change their contracts. Sometimes the new functions will be valuable in their own right. Some only to the trait hierarchy, some is just grunge implementation. The last mark as private[this].
The implementation isn’t any more complex for using multiple functions. It usually is more understandable. It also helps one reframe the method into true functions. A valuable learning too, even if you go back and merge the code. While one cant really do functional programming in Visual Basic, this exercise will give many functional programming style benefits. The exercise usually reduces code size by bunches. Half or a quarter LOC is pretty common. I had my smalltalk and java programmers do this, and they became much better developers.
Again, even if you roll it back afterwards, you still will have better code. Leaving it unrolled usually makes testing very simple. Every method does one thing. It almost always help understand what went wrong enough that the coded needed a return in the middle of it. It needn’t cause any changes to public contracts, though some times it discovers a valuable behavior to add to the contract. That’s essentially how we ended up with map, fold and other iconic FP behaviors.
Agreed. I wrote up something closely related to this recently: https://dev.to/yawaramin/lift-functions-up-into-the-toplevel-4j57