3 ms·
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,
by fknorangesite 3y ago
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.
- whstl 3y agoThis 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 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.
- vidarh 3y agoI 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.