[bartc]

15 years experience (mostly java) here... I agree with senior developer. You're needlessly breaking the logic across multiple files to handle potential use cases that may never come up. It's not horrible, but if you have 100 of these controllers, now you need 100 service objects (or maybe 50 if you can group things). All to keep the extra three lines of code out of the controller.

Keep things in one place to start and then if the need for sharing or abstracting comes up I the future, refactor the code.

This approach should be reversed if you're shipping a library for use by third parties (abstract and isolate everything you can).

[mjs]

"This approach should be reversed if you're shipping a library for use by third parties"

I'm coming to believe more and more strongly that there should be a difference in the way writing library code, and writing code that uses libraries, is approached. (This applies to the use of design patterns, abstractions, and various other "best practices.")

In many cases, there's a big difference in both programmer quality and the amount of time spent on each line of code between library code and application code. And worse, most of the time, when programmers come across good code, it's library code, not application code. This leads programmers to think that library code--with its multiple abstractions and design pattern complexity--is the right way to do things, and so then then apply this approach, quite inappropriately, to their application code.