> 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).
> 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.
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).
>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.
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.
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).