You do not need inheritance with OOP | Hacker News Reader

You do not need inheritance with OOP

r.je

44 pointsrevskill19 comments

No, but then you find out you don't need OOP either.

Dynamic dispatch and parametric polymorphism are also part of OOP.

You can have both without OOP (at least not in the sense of a hierarchy of classes, or any C++/Java style), so...

"In the sense of a hierarchy of classes, or any C++/Java style)" is not the point of view of SIGPLAN, ACM or IEEE research about how a OOP language is supposed to be.

As a former OOPSLA attendee, I rather fallback on their opinion.

>is not the point of view of SIGPLAN, ACM or IEEE research about how a OOP language is supposed to be.

Which is neither here, nor there. It's how OOP is thought of and practiced in real life by the statistically significant majority, so that's above what Alan Kay thought it should be or what SIGPLAN or the ACM or IEEE thinks "how an OOP language is supposed to be".

Terms take their meaning from actual mass usage, not from their inventors or what researchers think they should refer to.

I recognized the limitations of class- rather than object-based OOP early on and was glad to find out that's not what OOP was meant to be. Now I understand when people say OOP they mean class inheritance and not much else. Still useful for graphical widgets and some other places where inheritance works well.

Alan Kay defined one way of doing OOP, which was already a departure from Simula, and both of them are two measure data points on the OOP tree of language design.

Most mass users don't have PhD papers in language research, and whatever most think is wrong.

>Most mass users don't have PhD papers in language research, and whatever most think is wrong.

Just not when it comes to language. OOP as a term is what programmers (majority) uses the term to refer to. In language you can't go wrong using a term as the majority does it - with language not being prescriptive, and being all about communication and shared meanings, and such. That's so strong that even established words, idioms and terms will change definition if they started using differently (awesome doesn't mean "inspires awe" anymore, and dictionaries have had "literally" as also meaning "figurativelly" and used for emphasis, since before we were born).

If having "PhD papers in language research" is a prerequisite to use a term "correctly" and the majority uses it otherwise, then the term has long changed meaning. That doesn't change just because a term is technical, as technical terms are also shaped by shared mass usage, not origin or etymology. People with PhD's in linguistics agree.

So OOP as commonly used is useful to understand what most other programmers mean, is useful to understand how most programmers who think they do OOP write code, is used in books about "OOP programming", is how the term is used in introductory classes about OOP, and is how people understand OOP in the most popular languages such as Java, C++, Python, and so on (even Javascript, where prototype inheritance is often seen through OOP lens).

And OOP "the real meaning" (itself still debated between what Kay meant, what Simula set, and other definitions) is only useful to refer to a set of historical ideas out of use today, to talk to a few people with "PhD papers in language research" and to agree with other pedants.

There is what common people think they know about, and there is science.

Taking the animal example here... if you do it the way the author suggested, then would the semantic meaning of $cat, $dog, $cow be lost somehow? (In that they're all an Animal). If you later on realized that $cat needed to do something special (i.e. have the graceful_landing property that no other animal has) - how is that done?

Just wondering - I'm a newbie at OOP :)

You can introduce intermediate classes: Animal > GracefulAnimal > Cat. The problem is if there's other branches that are also graceful that there's no way to include just the right subset. That's where composition is better in that a Graceful aspect can be mixed-in.

It's basically the same problem of categorizing with labels in a single tree structure. You often find you want to group lower subtrees without including their parent nodes. That's why Gmail labels are better than normal email folders.

I have a common personal use-case for inheritance:

If I'm forced to use a framework that infects my whole codebase, e.g. Spring, it's often possible to escape the infection by splitting a Service into a SpringService and a LogicService. LogicService thereby remains testable and doesn't depend on Spring. The way to connect them is to have the SpringService inherit from the non-spring service.

That said, I'd rather have neither Spring nor inheritance.

It's funny how times have changed. Spring used to be that (micro)framework that prevented your code to depend on anything framework related. And here we are now...

I have been avoiding inheritance like the plague since at least 15 years ago and enjoying the pleasure of working with Spring for the same amount of time, approximately. But nowadays looking at what people do with Spring makes me extremely sad. Every time I find people "injecting" things by using annotations I can just think "WFT? Haven't we learnt /anything/?"

No, nothing's changed. Spring still infects your whole codebase. Just look at the imports, or try to run your code via a different framework if you think I'm exaggerating.

Its proponents still make the same claims about it protecting you from coupling, not causing it.

Spring does not need to infect your codebase. You can use the container without importing anything from Spring in other than one class (the one bootstrapping the system).

If you want to use Spring classes in the implementation of your clases then yes, you will need to import them. But this is no different than any other library.

If you just use XML configuration files (or use @Configuration) you don't (shouldn't) use @Inject, @Autowire and all other abominations. Or at least you didn't need, last time I checked a couple years ago. All your code is clear, free of any Spring code (unless you use some of the libraries) and fully reusable, testable, etc.

Why everyone moved to annotations for "dependency injection" (that crap is NOT DI!!!!!), not only in Java, but Python, Typescript, etc. I just can't understand. It can't only be the convenience of doing so by saving some keystrokes, but I just can't get it. We solved the modularity beautifully with Spring (and other DI engines) and then we proceed to throw away the solution and recreate the problem again? Get off my lawn...

If you use constructor injection services are unit testable without touching Spring.

Then can I remove those imports?

Mock the dependencies in the constructor and test.

Why are you talking about removing imports?

I do use constructors.

I'm refuting the claim that my unit tests won't touch Spring.

If my unit tests don't touch the Spring stuff in my class, either my unit tests on that class are woefully incomplete, or I didn't need the (explicit, directly-coupled) Spring stuff in my class.

Reply on news.ycombinator.com