If it helps at all, keep in mind that many people who think they're doing object-oriented ruby are actually doing functional programming. Take a look at the Ser

If it helps at all, keep in mind that many people who think they're doing object-oriented ruby are actually doing functional programming. Take a look at the Service Object pattern--A globally accessible reference with a singular method class (`.call`) that takes arguments and returns a singular value, and without you ever interacting with an instance of the class, etc etc. This is just a function in disguise! Every true service object could be reimplemented as a proc without the rest of the codebase knowing anything changed. Writing Object Oriented code is hard. If you don't have a solid understanding of SOLID, at best you end up reinventing functional programming, at worst you end up with a big plate of spaghetti code. That's why most ruby codebases are a huge mess. It's still my preferred approach, but it's certainly not for everyone, and it's certainly easy to muck up. Thankfully Ruby is flexible and allows both--people just need to be honest about what they're actually doing, and not present any implementation of Ruby as object oriented.