I understand where he's coming from, but on the other hand it sounds like he's trying to avoid saying "maybe that OOP thing isn't all it was cracked up to be".
I think that is more descriptive and less prescriptive.
I’ve never seen a codebase ever really use OOP in an enterprise setting. Just spaghetti and meatballs architecture. Meaty god objects “services” with long strings of structs.
> 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?
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.
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.
> 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.
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.
Or more about boundaries, like in less Monoliths, and more micro services and container deployments including cloud functions like AWS Lambda and Azure Functions. And "coupled by less strongly typed schemas" is more of a fact statement, but is it really a good thing?
Software Engineering will not progress into real Engineering, until it starts building on the past instead of throwing away past lessons. OO was about many things but particularity about code reuse. Is that also a bad thing?
>OO was about many things but particularity about code reuse. Is that also a bad thing?
No - but OO wasn't as successful at delivering code reuse as it was promised to be, especially polymorphic OO.
>Software Engineering will not progress into real Engineering, until it starts building on the past instead of throwing away past lessons.
SE won't be real Engineering until we start being able to do things like measuring the robustness of a system, or projecting it's maintenance costs. I think we are as far away from this as we've ever been.
Unfortunately, while OOP promises code reuse, it usually makes it worse by introducing boundaries as static architecture.
OOP's core tenet of "speciating" processing via inheritance in the hope of sharing subprocesses does precisely the opposite; defining "is-a" relationships, by definition, excludes sharing similar processing in a different context, and subclassing only makes it worse by further increasing specialisation. So we have adapters, factories, dependency injection, and so on to cope with the coupling of data and code. A big enough OOP system inevitably converges towards "God objects" where all potential states are superimposed.
On top of this, OOP requires you to carefully consider ontological categories to group your processing in the guise of "organising" your solution. Sometimes this is harder than actually solving the problem, as this static architecture has to somehow be both flexible yet predict potential future requirements without being overengineered. That's necessary because the cost to change OOP architectures is proportional to the amount of it you have.
Of course, these days most people say not to use deep inheritance stacks. So, what is OOP left with? Organising code in classes? Sounds good in theory, but again this is another artificial constraint that bakes present and future assumptions into the code. A simple parsing rule like UFCS does the job better IMHO without imposing structural assumptions.
Data wants to be pure, and code should be able to act on this free-form data independently, not architecturally chained to it.
Separating code and data lets you take advantage of compositional patterns much more easily, whilst also reducing structural coupling and thus allowing design flexibility going forward.
That's not to say we should throw out typing - quite the opposite, typing is important for data integrity. You can have strong typing without coupled relationships.
Personally, I think that grouping code and data types together as a "thing" is the issue.
Pet_Ant|1 year ago
I’ve never seen a codebase ever really use OOP in an enterprise setting. Just spaghetti and meatballs architecture. Meaty god objects “services” with long strings of structs.
belter|1 year ago
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?
usrusr|1 year ago
sirwhinesalot|1 year ago
Everytime.
marginalia_nu|1 year ago
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.
lenkite|1 year ago
I have seen lots of them. Fairly maintainable ones too for that matter. With minimal spaghetti code.
baq|1 year ago
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.
vbezhenar|1 year ago
belter|1 year ago
Software Engineering will not progress into real Engineering, until it starts building on the past instead of throwing away past lessons. OO was about many things but particularity about code reuse. Is that also a bad thing?
sgt101|1 year ago
No - but OO wasn't as successful at delivering code reuse as it was promised to be, especially polymorphic OO.
>Software Engineering will not progress into real Engineering, until it starts building on the past instead of throwing away past lessons.
SE won't be real Engineering until we start being able to do things like measuring the robustness of a system, or projecting it's maintenance costs. I think we are as far away from this as we've ever been.
arc619|1 year ago
OOP's core tenet of "speciating" processing via inheritance in the hope of sharing subprocesses does precisely the opposite; defining "is-a" relationships, by definition, excludes sharing similar processing in a different context, and subclassing only makes it worse by further increasing specialisation. So we have adapters, factories, dependency injection, and so on to cope with the coupling of data and code. A big enough OOP system inevitably converges towards "God objects" where all potential states are superimposed.
On top of this, OOP requires you to carefully consider ontological categories to group your processing in the guise of "organising" your solution. Sometimes this is harder than actually solving the problem, as this static architecture has to somehow be both flexible yet predict potential future requirements without being overengineered. That's necessary because the cost to change OOP architectures is proportional to the amount of it you have.
Of course, these days most people say not to use deep inheritance stacks. So, what is OOP left with? Organising code in classes? Sounds good in theory, but again this is another artificial constraint that bakes present and future assumptions into the code. A simple parsing rule like UFCS does the job better IMHO without imposing structural assumptions.
Data wants to be pure, and code should be able to act on this free-form data independently, not architecturally chained to it.
Separating code and data lets you take advantage of compositional patterns much more easily, whilst also reducing structural coupling and thus allowing design flexibility going forward.
That's not to say we should throw out typing - quite the opposite, typing is important for data integrity. You can have strong typing without coupled relationships.
Personally, I think that grouping code and data types together as a "thing" is the issue.