[mxmbrb]

This is the perfect example. You start out like that and all is fine, but two years, a few changes and some bugfixes later your now 2700 line method is a total zombie. The comments blocks are lying and you have incromprehensible dependencies. More over you have to read it all every time you make a change in the method, its inputs or understanding its output. That just screams 'refactor me!'. The exceptions of course are when initializing a lot, or having a ton of bindings, etc. No need to cramp this into sub methods like its a religion.

Cramping code may be fine for high performance code where the mandays are justified for the two line code fix. But in most Software you likely just want to include the new cache methods, change the used object, add a button or fix an update. And the person fixing it probabaly hasn't seen the specific code ever before. There is sadly no need for high performance software, when you can't sell it in time.

[curtainsforus]

If you want logical separation, add sub-blocks to the function. You can see things as being a spectrum from fully inline code, to code blocks, to anon functions defined in the function, to true functions.

[jbverschoor]

Still better than nested classes and 50 different places where the code is. There are plenty of places where it makes more sense. Also in 'normal' code. It's about readability and maintainability. Classes mean -> extensibility, and is by definition more complex. Factoring out some functions make sense yes, but not the general mantra "if it's 5 lined it should be a function".

As Uncle Bob says (paraphrasing): Dependency injection (java) is just programming XML where you turned compiler errors into runtime errors