Because of SRP.
Care to give an answer better than "some book some java dudes wrote 20 years ago said so"?
While I generally agree with SRP, when that single responsibility can be expressed in a single function, I don't see the win with have a class dedicated to it. Smells of pedant OO nonsense.
Is not instantiation etc a cross-cutting concern that violates SRP in this instance?
Right.
Which is why hes also recommending the use of DI.
It's hard to strike a balance between a strong design which takes a lot of time to work within, and one that just allows you to get things done, but once your project begins to grow in size and complexity, and testing becomes even more important, these things really do start to matter.
It's difficult to internalize until it's bitten you on the ass, hard.
That said, if you have a large amount of single method classes, you might need to take a look at why you need them and find a better approach (which will vary from project to project).
The whole point of objectify is that it actually makes it pretty reasonable to work this way right off the jump. I would have a hard time believing that it's really any more work to build an objectify app than it is to build a vanilla rails app - at least once you become accustomed to the paradigm.
> That said, if you have a large amount of single method classes, you might need to take a look at why you need them and find a better approach (which will vary from project to project).
I don't buy that. My project has hundreds of single method classes and it's by far the best factored non-trivial application I've ever seen (anecdotal, obviously, but so it goes).
Sure. I wasn't saying otherwise. What I meant was, in a general sense (prior to really seeing the benefits first hand), it can be hard for people to justify the trade off when they feel like they can just "get it done faster" with a more ad-hoc approach to things. I didn't mean to imply Objectify was some how more difficult (I haven't used it, so I wouldn't dare comment on it in such a way).
>I don't buy that. My project has hundreds of single method classes and it's by far the best factored non-trivial application I've ever seen (anecdotal, obviously, but so it goes).
Agree to disagree, with a caveat. I'm not against having a large amount of "Helper" or in the case of what I'm most familiar with, "Extension" classes (godbless you, .NET Extension classes), but I think if you have so many that they comprise most of your code base, maybe you could consolidate some of them (and maybe you couldn't).
Personally, I try to keep 100% of my core business logic inside of "Service" style classes, and then anything that is more of a helper (in that it performs some work, but not "business logic", and does not require or alter internal state) in either a static helper, or an Extension on the type itself.
For example, I usually end up adding a .ToStart/EndOfDay/Week/Month suite of methods to the datetime object of most of my projects. A "DateTime Service" would be overkill, but an extension method (which is just veneer over a static helper) fits the model perfectly, in that it returns a new copy of the existing datetime, leaving the original intact.
But at this point we're getting pretty deep into the comment tree, so feel free to email me from my profile if you want to go more into the issue - I love shooting the shit over this kind of stuff. Regardless of any minor difference of opinions, I think what you're trying to bring to the rails community is to be commended.
Thanks a lot, man.
Also, those are not really single-method classes, but single-method interfaces. Since you didn't give any arguments, I don't see how those two extra lines to define a class have any disadvantage in comparison to a global method, and having the framework define a interface to program to leaves more flexibility to the framework user than having the framework accept a method name or block instead. The instatiation of the class can be left to the framework user (in general, I don't know if this is the case here in particular) so that additional data can be attached, inheritance can be used (yes, inheritance has its problems, still it also has plenty of valid usage scenarios), methods broken down into smaller private methods etc. Also in Ruby there are no global methods like you would have in Python or C++, you always define a method of some class, even if it's in the top-level scope - files almost always correspond to individual classes so it would be pretty odd to have methods used here instead.
I think I'll have to give objectify a try and see how it all fits together. It's a different enough approach to what I'm used to that I probably don't have a reliable intuition as to how it'll turn out in practice.