People don't like (implementation) inheritance, for good reason. But that's not the core of OOP, that's some weird crap people piled on top of OOP in the 90's.

People don't like (implementation) inheritance, for good reason. But that's not the core of OOP, that's some weird crap people piled on top of OOP in the 90's. Object-oriented programming, fundamentally, is about associating code with the data it manipulates. Code + data = object. Two essential follow-ons: * Encapsulation: Your object provides an interface composed of methods, without allowing callers to reach in and mess with the data inside except by calling those methods. This allows your implementation to evolve without breaking callers. * Abstraction/polymorphism: Objects with different implementations can implement the same interface thus making them interchangeable. This enables code which operates on such objects to be reused across wildly different use cases. These fundamentals exist in basically all large systems. Example: Linux file descriptors are objects. Different kinds of file descriptors (e.g. disk files vs. sockes) implement the same interface (syscalls, e.g. read/write), and you cannot reach directly into their implementation from userspace, which allows the kernel implementation to evolve over time. You really can't not use OOP in these scenarios. The opposite of OOP is separating code from data. In anti-OOP, you declare your data structure completely transparently, without declaring any kind of "methods" that apply to it. Code modules interoperate by operating on the same underlying structure. This tends to lead to sclerosis as adding new features to the data structure without breaking existing code can be quite difficult. My hot take: The philosophy of REST (though less often the actual implementation) is disturbingly anti-OOP.