|
|
|
|
|
|
by jambox888
3570 days ago
|
|
|
Yeah, I was going to say, OO is brutally overused and seems to be fading quite quickly in the new world of highly scalable systems, e.g. Spark, CouchDB and so on. Objects still have a place in widget sets, datetimes, etc. Overall though they were often used by default where there were better ways and just as often abused to allow a ton of shared state (globals in disguise), which almost always makes code harder to follow. |
|
|
The problem is that the way most modern systems are scaled, they are very short lived. When the purpose of a code base is to turn HTTP requests into SQL queries and SQL results into HTML responses, then the objects end up being a thin layer between function calls.
That's not a necessary outcome; in a parallel universe something like Prevayler would have given us long-lived object graphs in a lot of the places where we now use OO languages on top of external databases. But that's sure not the world we live in.
Another factor that I think made things worse was the massive increase in the number of programmers during the Internet boom. I love working with code from master OO developers, especialy those of the test-driven, domain-driven sort. But OO approaches allow so many degrees of freedom that it's easy for relatively junior developers to make giant messes. Messes that I don't even think of really as OO, just snarls that happen to be in OO languages. Regardless, I think the September That Never Ended kept the average OO code base in a state much worse than the best ones.
Anyhow, I'm excited to see the state of practice moving forward, inch by inch.