> 6 classes to solve a problem that could be done in a single 2-screen long function

Isn't the former promoted as better programming? IoC, decoupling, Law of Demeter, testability etc

All of those things being "better" include an implicit "...in the context which these best practices were studied" which usually means large teams of just-OK programmers writing Java code that mostly doesn't need to perform very well but will be changed a lot, and needs to be very consistent in style and pattern so that when an intern comes in and pokes it as his first commit he can't do any serious damage.

You can imagine a million ways those assumptions break down, as well as a million ways they seem to but should actually be stuck to. Knowing the difference is the tough part.

Both of the examples above are actual things I've seen. As for this one, it was not better programming, it was just over-engineered. I think that over-engineering is a stage all developers go through in their career. What is considered "better programming" certainly contributes to the problem.

It took 4 times as long to produce the solution that was 4 times bigger and more complex than it needed to be. Maintaining that huge body of code forever is more than 4x the effort over time than a single small function. And that's how you get a 0.25x (or less) programmer.

There is probably a good middle ground. If it's a "once off" sort of task, then there is no need to over-engineer it to perfection.

The sweet spot has a nice tradeoff between extra-time spent, and ease of migrating to a full-blown complicated and extensible solution. For me, I generally write my code in that middle ground. Stubbing out parts of my solution and then coming back to fill it in. In that sense, having separate functions with clearly-defined input/outputs or portions of work, aides me in completing my solution.

Promoted? Yes. Actually? No.

So, genuine question, why?

You scatter the code all over the place, making it harder to understand and less flexible (less flexible, because if you want to change something, now you have to change it in six places).

Best practice doesn't mean "make as many classes as possible" although I would probably break up two-pages into a few different functions (large functions, even when they are good code, invite programmers who come later to add to them in a messy way).

If you have to change it in six places it just means that you did something wrong. Keeping those six places in the single file is not the solution either: next time you will need something similar, but not exactly the same you will copy that file. And next you will find yourself changing twelve places.

The good rule of thumb is not to refactor into reusable parts unless you need to do something similar. It isn't hard, at that point, to split things up. Premature design is like premature optimization -- you do the wrong things, or things you never need to do.

And yes changing things in six places means you did something wrong, but that's easy to do when you start by splitting things into six places. The worst, of course, is when developers don't change it when it needs to be changed and instead just keep adding. Once you have something so designed it makes removing and changing code more painful than adding code.