I've said this multiple times over multiple years and I'll say it again just because so many green developers get misled.
Object oriented programming is good. Not in absolutely every situation, but for most business applications it's better than the alternatives. The reason it's good is that it is productive. Objects map neatly to records, which pushes global state persistence and all the hairiness of locks to a good RDMS like Postgres. It's naturally normalized, but can be denormalized without much work, and in exchange for bundling state with functions you get easier introspection which is especially helpful in debugging.
These conversations are better done with examples. Say you want to build a social network around videos, like YouTube. Say a user can block another user and, thus, stop them from commenting on their videos.
Would you rather type out this:
user.blocked_by? other_user
Or this
is_blocked(user, other_user)
When doing the check? Personally, seeing the the is_blocked? method on a user makes it easy for me to understand. Who has blocked whom is more natural to talk about when there is a primary object subjecting the other object to a test. For all the anti-OO stuff out there, it all boils down to the same thing in the end. For business logic, your functions need to know so much about the data that they are operating on that it's pointless to try to avoid bundling the state. I'm never going to pass a cheeseburger into my is_blocked function so why on earth would I avoid bundling state and operation together? It's like a map of a city trying to avoid listing shops since "maps should be about roads and geography, not shops." A pointless dogma that doesn't actually help programs get built. Most successful startups use OOP and there is a clear reason for that: It's more productive.
Now, do I use OOP when I'm doing data science stuff? Mostly no. I don't need it there. But where it works, it's magic.
Object oriented programming is good. Not in absolutely every situation, but for most business applications it's better than the alternatives. The reason it's good is that it is productive. Objects map neatly to records, which pushes global state persistence and all the hairiness of locks to a good RDMS like Postgres. It's naturally normalized, but can be denormalized without much work, and in exchange for bundling state with functions you get easier introspection which is especially helpful in debugging.
These conversations are better done with examples. Say you want to build a social network around videos, like YouTube. Say a user can block another user and, thus, stop them from commenting on their videos.
Would you rather type out this:
Or this When doing the check? Personally, seeing the the is_blocked? method on a user makes it easy for me to understand. Who has blocked whom is more natural to talk about when there is a primary object subjecting the other object to a test. For all the anti-OO stuff out there, it all boils down to the same thing in the end. For business logic, your functions need to know so much about the data that they are operating on that it's pointless to try to avoid bundling the state. I'm never going to pass a cheeseburger into my is_blocked function so why on earth would I avoid bundling state and operation together? It's like a map of a city trying to avoid listing shops since "maps should be about roads and geography, not shops." A pointless dogma that doesn't actually help programs get built. Most successful startups use OOP and there is a clear reason for that: It's more productive.Now, do I use OOP when I'm doing data science stuff? Mostly no. I don't need it there. But where it works, it's magic.