Hacker News Reader

Comment by fknorangesite | Hacker News Reader

Yes, but that's because the example we were given in this thread is just a toy strawman in that each of the methods are just simple one-liners anyway. So yeah, given this literal code sample, I agree the private methods are extraneous.

The point of this pattern is to extract each operation into its own described-by-name method because they're each longer and more complicated than just a `<<` operator or whatever.

View on HN

This is why it's difficult to have discussions about this. Pretty much anything that's bad enough will be countered by a "well, this is just a toy strawman", and status quo will prevail.

Well, here's some production code from a previous project which I happen to have authorization to use for educational purposes, with entity and fields anonymized as courtesy of ChatGPT.

https://pastebin.com/wLk5bRqE

This is by no means a rare thing in Rails world, and I have seen this in pretty much every Rails project I worked, save for one.

Every single time: newcomers would complain about it. Even senior/staff engineers. Only the people building it enjoy it.

I agree that is the point of this pattern. But in practice most places where I see it employed are full of single line method bodies because people have heard of the pattern but don't understand the (fairly frankly rare) instances where it is appropriate and/or don't understand when an operation is long enough that it makes the code clearer to break it out.

Overall I see this pattern as a net negative - I've yet to work on a project where more than a tiny minority of service object classes have any reason to be one.

Reply on news.ycombinator.com