I’d argue you’re right until you need to track down a bug in the code. Then, to the author’s point, you have to jump back and forth in the code to figure out all the interdependecies between the methods, and whether a method got overridden somewhere? What else calls this method that I might break by fixing the bug? (Keep in mind this example fits on one screen - which is not usually the case.)
all these debugging problems are still better to solve than if all the code was in the same scope like on the left side. It’s not worth exchanging possible overriding or data interdependency for a larger scope.
I’d argue you’re right until you need to track down a bug in the code. Then, to the author’s point, you have to jump back and forth in the code to figure out all the interdependecies between the methods, and whether a method got overridden somewhere? What else calls this method that I might break by fixing the bug? (Keep in mind this example fits on one screen - which is not usually the case.)
all these debugging problems are still better to solve than if all the code was in the same scope like on the left side. It’s not worth exchanging possible overriding or data interdependency for a larger scope.