OOP is the perfect fit for <10% of every codebase I've worked on. It is so good for that 10% that it encourages people to wonder if perhaps it should be applied

OOP is the perfect fit for <10% of every codebase I've worked on. It is so good for that 10% that it encourages people to wonder if perhaps it should be applied everywhere else. Many software engineers love consistency more than anything else, so when OOP works so well for that fraction, it looks "untidy" to have several different styles spread throughout. OOP apologists preach that it should be everywhere even if it doesn't make sense, so there's social pressure to force it all the places it's not needed. For example: unit testing is almost impossibly hard with OOP. Encapsulation and OOP-flavored dependency injection add significant complexity when setting up a single function to unit test. You have to use extremely complex mocking libraries to test anything. On the other hand, pure static functions are trivial to test, just pass in the data and test the data coming back out. Yet OOP apologists still argue to this day that extremely difficult unit testing is worth it for the dubious benefit of having the whole codebase feel tidy. Let's take the concept of interfaces in OOP as used for polymorphism. An interface is fantastic for swapping out multiple behaviors or strategies at runtime. Very handy. However, how many times in an average software project are they actually needed? A favorite trick I like to do with OOP codebases is count how many interfaces have more than one implementation (not counting unit tests). I recently helped a team with a project with ~4 million lines of C#. There were ~900 interfaces, and 6 of them had more than one implementation. The rest of the interfaces were just for unit test mocking. Not needed for polymorphism, just unit test cruft. Those 894 interfaces were mocked out only in unit tests. Each of their 10k unit tests was on average 60 lines of mocking logic. For the 6 places it was needed, a polymorphic interface was a great solution! The rest though, not needed at all, and if they'd reorganized the logic into pure static functions they could cut back most of those 60 line unit tests into 4-6 lines. Instead of 600,000 lines of unit test logic, they'd only have 60,000 lines. All that mocked out unit test logic was slowing them down considerably. Every tiny little change required fixing thousands of lines of brittle unit test logic. This is just one dimension, but it's an important one. OOP is great in those few rare places it's needed, but the rest of the time it's a square peg in a round hole.