Indeed! This has always mystified me. Why is it so easy to implement what is now considered to be an anti-pattern (inheritance) when it's so boilerplate and annoying to implement composition? Why does C# not have language support for delegating members? Why do I have to buy and use ReSharper just to generate all that boilerplate? It's a constant battle talking to "just get it done" developers about why inheritance is bad.
Inheritance is only considered an anti-pattern by some.
Since the 90's, any good CS book about OOP paradigms had discussions about is-a and has-a and how to make the best use of each, depending on the desired application architecture.
The thing is, such books usually aren't taught on bootcamps.
Inheritance isn’t an anti-pattern in academia. I do part time work as an examiners for CS students, and I see their car/animal examples everywhere in introductionary courses.
When we have interns, they’ll sometimes build things with inheritance. So it’s certainly still a thing.
I’ve yet to see a real world use of it, where you wouldn’t have been better of not using it though. My real world is the relatively boring world of enterprise public sector software, however, and maybe I’m simply oblivious to where inheritance might be worthwhile.
That is the thing, the architect should have a proper understanding of is-a and has-a relations and apply them appropriately.
Initially, VBX only allowed for composition as well, COM introduced interface inheritance with delegation, when one wanted to override a couple of methods, but not the remaining several ones.
And now UWP offers mechanisms to do implementation inheritance in COM, because everyone got tired to write delegating code for is-a relations.
Inheritance and composition are both tools, it is up to each one to learn how to use them appropriately.
