Your overall recap is on point. Wrt this point, here’s a different way to look at it. You could keep focusing on identifying what’s wrong with OOP, or you could instead work on identifying alternative patterns that provide clear advantages in one situation or another.
As an example, see Andrew’s talk about DOD:
In it you will see that he doesn’t waste a single word talking about OOP being bad, and instead focuses entirely about the good properties of DOD.
So after you know about this approach, then the next time you have to design something, you can make a more informed choice.
I’ve written some parsers for the languages related to Zine and, while I have yet to go full DOD, I’ve stayed away from many OOPy patterns, not because I focused on what’s wrong with them but because the alternative provides advantages that are relevant to my use case.
As an example my parsers put all AST nodes into a single array list and use indices into the array instead of pointers, which means that I have:
- Significantly reduced number of total allocations
- More compact data because of u32 indices vs u64 pointers
The day that I’m doing something where these properties are not as important (I like Zine being faster than any other SSG I know of), then I might go OOP if it makes sense, why not.