In this case the implementation is barely longer than the bare method-calls. It doesn't hide complexity, it increases it, because odds are you'll need to chase down at least some of those methods calls to be sure what it does.
To me, if someone tried committing that, I'd sit down with them to have a very long discussion about 1) why it will not be accepted into the code base ever, 2) which training steps to go through with them to level them up, because if they keep writing code like that, it'll be a negative effect on the whole team - at a minimum by forcing us to review and reject their code on a regular basis - and you can be 100% certain I would ding a developer on their performance reviews if they kept writing code like this (I would give them a chance to learn not to first, but if they kept it up?)
> When you inline those tiny functions, as the author argues for, now the reader has to recognize what each implementation line means. Of course we might say it's obvious, but it's less consistent and clear than a series of calls to functions which are well-named and take arguments which are well-named.
Each of those are obvious to anyone familiar with Ruby ORMs, while the methods calls are not for the very reason you go on to give:
> And as software engineers of any experience, we know that eventually one of those "simple" actions will become more complex due to some new requirements.
This is exactly why hiding the simple calls in a method is an awful code stink, because it signals there may be more to it than just a single method call, and so to be sure I know what is going on I will need to chase down each method call.
That's fine if the method calls are actually encapsulating complexity. It's not fine when they're hiding simplicity.
When the complexity grows, then you've justified a separate method.
> As for maintaining state, I personally argue against any OOP style. All of those action functions can just be functions in an appropriately-named module. They should all take input arguments (the data), and ideally not even mutate the input but rather return a value. That value could be a new version of the input data (can be memory/time expensive, so not always the best choice), or they can be just a data structure of changes.
Ruby doesn't have functions, only methods of an object. You can pretend a method in a module isn't a method of the module object and doesn't carry state, but it does, and ignoring that means throwing away what makes Ruby powerful. E.g. making use of those abilities makes implementing monads, composition/currying etc. trivial to achieve, and sometimes having that ability is valuable and improves the ability to instrument code for example.
Put another way: If I call SomeNamespace.foo, I don't know from the fact that it looks like a module or class whether it carries state or not, because SomeNamespace is just another object, and as long as you're disciplined about how you use it, that's a good thing.
But whether or not you prefer that is besides the point. The point was that if you need or want your "user creator" to maintain state, in Ruby an object with instance variables leaves the instance variables accessible no matter what you try to do. If you're fine with that (or want that), use a regular class. If you want to prevent any tampering, use a lambda. Either way, if a class has only a single reasonable action to take on it, the method name by convention ought to be `call`. Those were the points I was making about state. You don't need to use it, but it's something to be aware of.
> I'm not a fan of lambdas, however, as they require more human memory to keep track of what's going on in a system.
A lambda in Ruby is just an object of the class Proc representing a closure. It does not inherently contain any more or less state than any other object. However it gives the benefit of being possible to pass to anything that either expects a Proc or expects to be able to `.call` an object, and when used properly that allows for a powerful level of composeability.