At its core, I view OOP as organizing code so the data and the methods that act on that data are linked. Usually there are some compile time restrictions on who

At its core, I view OOP as organizing code so the data and the methods that act on that data are linked. Usually there are some compile time restrictions on who can touch the data. You are able to be sure some state is valid because only this class can touch the state. If you think of OOP like that, it seems trivially good. Surely a lot better than a bunch of raw data hanging out that anyone can mutate at any time. Inside of some class, you can then implement whatever you want inside of that class, ie:struct of arrays, or w/e. I don't view "inheritance" as a necessity of OOP. Composition fits great. I don't view "array of structs" as a necessity of OOP, nor over usage of heap allocations and pointer chasing. People associate OOP with this, but it's not fundamental, it's a poor, out dated mutation. It seems like when people say "OOP is bad" they really mean "over abstractions are bad", and yes, they are bad, but "data oriented design" and "procedural code" isn't some silver bullet that's gonna save you from writing trash code. Ultimately, I consider ideal code to be "verifiable on sight". Ie; I can read it easily and mentally verify that it is correct. Bad code is code that is very hard to verify correctness by reading. There's an art to this and it doesnt always fit into these semantic buckets of "OOP" or "Data Oriented Design".