[rbxbx]

At first I thought this was an attempt at trolling, but then I noticed that Mr. Golick is the commenter so therefor I must assume serious intent.

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?

[tnm]

"some book some java dudes wrote 20 years ago" — If you're referring to "Design Patterns", the Gang of Four were writing about C++, it was 1994, and Java wasn't out yet.

[stiff]

I think you misunderstood each other, you meant a global method and Mr. Golick seems to have understood that you mean just another method in the controller or whatever.

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.

[manuscreationis]

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

[jamesgolick]

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

[jamesgolick]

I gave an answer better than that. Did you read the post?