The Rise and Fall of Object Oriented Programming
1–10 of 29 posts
Re: The Rise and Fall of Object Oriented Programming
#2It sure is trendy to knock OOP. This is at least a pretty measured commentary that doesn't condemn it altogether.
A lot of the current criticism of OOP targets aspects of the discipline that I don't think experienced programmers tend to use much anyway, like inheritance. I am just never compelled to create massive hierarchies, or even significant hierarchies.
Currently I'm even moving away from "encapsulation," finding the mindless creation of getter & setter methods to be wasteful academic tedium.
Re: The Rise and Fall of Object Oriented Programming
#3To those who enjoyed reading this article, I'd also recommend this one. https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
Re: The Rise and Fall of Object Oriented Programming
#4I've always felt so alone in my distaste for ORMs. They often lead to at worst taking way more data than you need and manipulating it all in a language that's not very good at it, or at best running some kind of query-builder which takes a far more complex configuration to get the same data that a simple query could. Objects make much more sense as something to build from a query, not something to be queried themselves.
If the tide is turning against ORMs, it probably has a lot to do with the rising love for fp that this author covers. Languages like SQL are declarative, as is fp, so that approach feels more natural to people these days.
Re: The Rise and Fall of Object Oriented Programming
#5Isn't the argument that there is nothing inherently wrong with OOP but like all things, it shouldn't be used exclusively?
For instance, working with language like Kotlin or C# it's fairly straightforward to get the best of both worlds: Use inheritance where appropriate, favor composition in all other cases.
IMO being dogmatic about not wanting inheritance altogether will result in friction as well: The fact that Rust eschews inheritance altogether will increase boilerplate whenever you want to do something that is 'inheritance-like'. Sure, people will argue that in 90% of the cases this is bad design, but for the cases where it IS the best approach it's a shame it's not part of your toolbox.
Re: The Rise and Fall of Object Oriented Programming
#6I've always felt so alone in my distaste for ORMs. They often lead to at worst taking way more data than you need and manipulating it all in a language that's not very good at it, or at best running some kind of query-builder which takes a far more complex configuration to get the same data that a simple query could. Objects make much more sense as something to build from a query, not something to be queried themselv…
I tent to consider database querying as constraint oriented programming, so indeed it does not fit either OOP or FP model. However, I do think that mapping database records to objects can be useful once they are in the program space.
Re: The Rise and Fall of Object Oriented Programming
#7> However, as the years went by, people started to realize that the strict approach to object orientation created a number of problems. These problems tended to be of the kind that makes code complex, hard to understand, and hard to test.
No, ease of testing is one of the reasons for OO adoption, and probably the primary reason software is much more stable than it was in the mid 90s.
> Many of those higher-level classes are “polluted” with methods and properties that are only relevant to a small number of subclasses.
Well, then it's broken and needs to be refactored.
> During my last couple years working at Google, I created a new user interface toolkit called “Quantum Wiz”
Of course, in true Google style, you wrote something from scratch instead of refactoring the old.
> composition > inheritance
Not a new finding. I learned this in 2000, at the peak of OO craze.
> Because object oriented inheritance is about organizing things into classes, it doesn’t model the real world very well; what it does model well is the way humans think about the real world.
That's the idea. Good software is written for the simplicity of those poor slobs charged with maintaining it -- often ourselves a year later.
> A physical object has many uses other than the specific purpose for which it was built. I can use a coffee cup as a paperweight or a doorstop;
The whole idea of modeling is to remove certain details! Otherwise the model would be identical to the genuine article, and would provide no benefit.
Re: The Rise and Fall of Object Oriented Programming
#8Isn't the argument that there is nothing inherently wrong with OOP but like all things, it shouldn't be used exclusively? For instance, working with language like Kotlin or C# it's fairly straightforward to get the best of both worlds: Use inheritance where appropriate, favor composition in all other cases. IMO being dogmatic about not wanting inheritance altogether will result in friction as well: The fact that Rust…
Inheritance is so natural to a GUI data structure. UI in Rust is incredibly painful. Probably a reason behind the CPU-wasteful "immediate mode" fad.
Re: The Rise and Fall of Object Oriented Programming
#9One use case where I found OO particularly unsuitable is applications that rely heavily on events.
Trying to understand what's happening is hard, when any call to your object structure can trigger changes at any level of your hierarchy, triggering other changes again, and so on.
Luckily, the rising popularity of Swift, Kotlin, and Go, will push for a more reasonable use of OO in combination with FP.
Re: The Rise and Fall of Object Oriented Programming
#10> However, as the years went by, people started to realize that the strict approach to object orientation created a number of problems. These problems tended to be of the kind that makes code complex, hard to understand, and hard to test. No, ease of testing is one of the reasons for OO adoption, and probably the primary reason software is much more stable than it was in the mid 90s. > Many of those higher-level clas…
Re: Well, then it's broken and needs to be refactored.
Refactoring means the original design didn't handle change well. Refactoring is badge of disgrace, and should not be considered a standard practice any more than putting out kitchen fires should be considered a standard practice of cooking. One of the key points of abstraction is to make the code change-friendly. If you have to refactor, the code failed that job. Minor rework is expected upon new requirements, but complete structural overhauls should be avoided, in part because it can create cascading side-effects.
Re: The whole idea of modeling is to remove certain details! Otherwise the model would be identical to the genuine article, and would provide no benefit.
But in some cases OO-based modelling becomes awkward or forced. Does the action of "gluing" belong with the glue or with the object being glued (fixed)? We can force it to be with one or the other to satisfy "OO rules", but that doesn't necessarily mean it's a good model. It's a forced model.
Re: [article] it doesn’t model the real world very well; what it does model well is the way humans think about the real world.
It doesn't model all thinking well. For smaller sub-systems it's fine. But OOP seems to get messy and tangled on a larger scale.