Object oriented programming isn't about an individual programmer.
It's about creating discrete APIs so that a bunch of different programmers can work on different aspects or sections of code.
It's an organizing principle for discrete elements that encapsulates internal state. You don't need to know your datastore is SQL or Redis, or Redis caching SQL data, or marshalled JSON, you just call Users.getUser(id), and get a User Object with a defined API.
OO is in many ways just microservices for a single codebase.
I think people ignore the importance of OO in terms of unit and integration testing.
Discrete apis and encapsulation don’t require OO at all. For instance in C you can easily encapsulate things by just not exposing it in the header file. Even things like data structures can be encapsulated by just returning a handle/pointer to a structure and not exposing the structure itself. The only thing OO gets you is embedding functions in the data structure.
Not sure where people are getting the idea that I'm saying that OO is the only way to do abstraction and encapsulation.
I'm saying it is a way, and a sometimes useful one. Certainly when I'm thinking about a SQL schema, I'm often thinking about it using OO design principles, even though SQL is functional.
It's about creating discrete APIs so that a bunch of different programmers can work on different aspects or sections of code.
It's an organizing principle for discrete elements that encapsulates internal state. You don't need to know your datastore is SQL or Redis, or Redis caching SQL data, or marshalled JSON, you just call Users.getUser(id), and get a User Object with a defined API.
OO is in many ways just microservices for a single codebase.
I think people ignore the importance of OO in terms of unit and integration testing.