Hacker News Reader

Comment by SkiFire13 | Hacker News Reader

Did you actually started to appreciate the same OOP that made class situations impossible to understand or did you gradually switched to a simplier OOP, made up of mostly interfaces and classes that implement them (as opposed to extending other classes)?

In my experience OOP is actually pretty pleasant to work with if you avoid extending classes as much as possible.

> These kinds of niche optimizations are still significant. The OOP model allows them to be implemented with much less fanfare.

If you're referring to the optimization in the article posted then I would argue an OOP model is not needed for it, just having encapsulation is enough.

View on HN

I'm not sure if the argument that OOP is pleasant so long as you avoid any OOP is a very sturdy one.

OOP is great for libraries but leads to overly complex codes for applications.

For a long time, Java was like, every classes is a library, i do not think it's a failure of OOP, it's a failure of Java.

But I'm optimistic, I choose to see recent additions like records and pattern matching has a step in the right direction.

I'd say that the 'poor man's closures' aspect of OOP - that is, being able to package some context along with behaviour is the most useful part for day to day code. Only occasionally is inheritance of anything other than an interface valuable.

Whether or not this is an endorsement of OOP or a criticism is open to interpretation.

OOP is the combination of encapsulation, abstraction, inheritance, and polymorphism. Ignoring inheritance does not mean avoiding OOP altogether.

Also note that the OP said “avoid extending classes”, but didn’t say “avoid implementing interfaces”, so they don’t disallow inheritance in a wide sense of the word.

I think “avoid extending classes” is there because it is as good as impossible to design classes that can be extended easily in ways you do not foresee, and if you do foresee how your classes could be extended, it often is easier for your users if you made your classes more flexible, to start with.

You can get Encapsulation, abstraction, and polymorphism any number of other ways. Inheritance is the only defining property of OOP.

If you removed all the stuff related to inheritance and trying to fix the leaky abstraction that is objects, the language would be a fraction of the size (compare with Go or StandardML for how small a language without inheritance can be).

And as for inheritance: Composition over inheritance. So .... just don't do OOP, I guess?

> Did you actually started to appreciate the same OOP that made class situations impossible to understand or did you gradually switched to a simplier OOP, made up of mostly interfaces and classes that implement them (as opposed to extending other classes)?

My thoughts exactly. Give me more classes with shallower inheritance hierarchies. Here is where I think go’s approach makes sense.

No. Things only get more complicated with more technical debt. The best you can do is manage it with yet another abstraction.

Reply on news.ycombinator.com