Hacker News Reader

Comment by robotresearcher | Hacker News Reader

In the early 2000s I often saw juniors and students make staggeringly deep class hierarchies. The equivalent of:

Shape::Polygon::ConvexPolygon::FourSidedConvexPolygon::Square::BlueSquare...

"Intro to OOP" lectures/articles made a deep impression on some people in not quite the right way :)

I was working at that time and never saw this from juniors. Overeager seniors and architecture astronauts, sure. But juniors? They mostly copy pasted code without even taking a second look at the codebase, and without bothering to break functions in any sensible way.

Mind you, I mean enterprise and line of business software, not hobbyists. I also mean of their own volition, not the kind of nonsense that Java frameworks often forced on them (all the patterns under the rainbow, factory abstract method factory of abstract methods).

I was probably that guy! It was all the rage 20 years ago, including worrying about the diamond inheritance problem. What is the equivalent in the current generation? ORM that no one can maintain? Unnecessary dev ops complexity? Anything "web scale"?

Are ORMs still a thing? I've been away from OOP for some years now, but just when I was leaving it, there was a trend firmly against ORMs... my guess was that they were on their way out, replaced by more lightweight libs and frameworks? Or did they make a comeback?

Regarding OOP itself, I also remember when "favor composition over inheritance" became a thing. Was this reversed too?

> Regarding OOP itself, I also remember when "favor composition vs inheritance" become a thing. Was this reversed too?

I think this is generally still the advice, when working in OOP contexts.

I agree from my extensive experience writing enterprise CRUD software. At this point, inheritance is like a plague that no one wants to touch. The best examples that I have seen are abstract base classes with insanely restricted overrides. If writing Java, imagine all of the public/protected methods are final except one or two. Wherever possible, classes are intentionally final to avoid any inheritance. To make a joke: "That shit is locked down!"

I love an ORM. I think much of the problems people experience with ORM, OOP, Restful routes, is because they get the domain model wrong. When you model the data correctly you don’t need to have complex queries that push ORM beyond their breaking point.

I think it's more complex than just about getting the domain model wrong. ORMs introduce tradeoffs and are inherently complex and full of caveats (both when deciding to use one or not), as amusingly pointed out in the much-discussed article from 2006: "[Object-Relational Mapping is] The Vietnam of Computer Science" [1]

----

[1] https://archive.is/QVPj (excuse the archive link, Ted Neward's blog seems now lost to linkrot).

    > I love an ORM.

No trolling: What langauge and what framework? One thing I can say from experience: I have seen some teams where they have deep knowledge of an ORM framework, and they are crazy productive when writing enterprise CRUD software.

    > Are ORMs still a thing?

In enterprise CRUD software: Absolutely.

    > favor composition over inheritance

I was very late to arrive to Java around 2015. This expression was wide-spread at the time. For those involved with "OOP" enterprise languages like .NET/C# or Java, when did "favor composition over inheritance" become dominant?

Reply on news.ycombinator.com