> I’ve never seen a codebase ever really use OOP in an enterprise setting

What!? Did you look at the source code of Chrome, QT, even Java JDK, SAP, Adobe, WebLogic, WebSphere....and so on...and so on...What kind of enterprise setting are we discussing here?

The code that uses those frameworks often works with turns into spaghetti and meatballs. Spring has real OOP, but code that uses Spring turns into DTOs and repositories and services.

That's because that happy family of business logic living in with state envisioned as a savior in the Smalltalk days turned out to be a hot mess. Information hiding does not magically make problems go away, in particular not when code isn't "write once and don't ever touch again" and state outlives code iterations. OOP has been a great contribution to how we organize code, but its principles are best applied in moderation. It's quite mindboggling to see how many people still believe they are followers of the OOP ideals when in fact they have long moved on.

Maybe you could clarify what OOP means to you ? There are lots of successful real-world OOP frameworks which have solved lots of problems.

With getters and setters as default whither "information hiding".

How people think that code is OOP when it has setters and getters, especially when then don’t do any validation is beyond me.

It’s just transaction scripts.

"You just didn't do OOP right."

Everytime.

See also: Agile, the word “political”, Big Data.

> I’ve never seen a codebase ever really use OOP in an enterprise setting.

I have seen lots of them. Fairly maintainable ones too for that matter. With minimal spaghetti code.

> I’ve never seen a codebase ever really use OOP in an enterprise setting.

That’s a very strong hint OOP does not solve any problems better than alternatives.

I think this is something programmers understood for a very long time but either didn’t care or didn’t have the tools to do better. Then go and typescript came along and showed the world that indeed structural typing is in practice better at almost everything, except perhaps GUI libraries. Maybe.

„Better than“ was never going to work for any paradigm. What actually works is „better together“, with a healthy mix of OOP, FP and SP.

> That’s a very strong hint OOP does not solve any problems better than alternatives.

It also requires more conceptually out of developers. I cannot count the amount of times I was on a team with developers that when implementing an interface never created a method that wasn’t one of the publicly required ones (ie no helper methods).

I think it depends on what you mean when you say OOP. I agree with the statement that OOP as it's taught in a text book with heavy emphasis on modelling the domain with deep inheritance taxonomies and polymorphism, that is largely a methodological cryptid.

These are tools that are relatively rarely used in Java. Not that they aren't ever done or used (anyone using almost any of Java's own APIs is knee deep in this), but the emphasis is in application code is typically on state-light services and immutable models. Not that I quite understand what is the problem with that.

OOP failed to deliver its promise. So people just use what's reasonable: split state into one structure and handlers into another namespace. So-called anemic model. Which is the only sane way to build software.

Especially if you count in 10-20 years of maintenance, bug fixes and small and bigger changes happening by various folks of various skillset and approaches.

KISS ruled, rules and will rule above it all.