I agree with you that the biggest strength of OOP is encapsulation that is easily accessible. As for inheritance, I think it is also a good abstraction, but in an very limited number of circumstances. In 10 years as a professional developer I have only ever implemented something using inheritance once. I think the problem with inheritance is that it is far too encouraged, and people fit it into problems which it is unsuitable.
Very true. Implementation Inheritance should be taught as one of the more obscure features of OOP instead of as one of the main features as it is taught often.
But in the end we should be less dogmatic in general . Myself and a lot of people I know started out building big inheritance trees only to find out that this didn’t work so well so we reduced it to a degree that was useful and manageable. But then you have some very loud dogmatists who scream “this is not OOP” and insist on building factories and factories of factories and all the other nonsense. And for some reason the dogmatists often get heard, maybe because they are so loud and convinced of themselves.
> In 10 years as a professional developer I have only ever implemented something using inheritance once.
If you build a library or framework, you'll use it more. There are often plenty of literal "is-a" relationships that don't exist as often in application code. So you probably benefit from inheritance in OOP quite a bit even if you aren't building those relationships yourself.
And now that I think of it, what I was building was a data visualization framework that users could create "plugins" for to handle many disparate types of data. So yeah, frameworks are a great example of cases where inheritance shines, but is rather niche and not many people work on them day to day.
I think the reason a lot of people reach for inheritance is because they're never really taught how to decompose a system into smaller moving parts through analysis. At a high level every watch tells time and date and has complications. But the devil is in the details of what watch we're talking about. And I think most classes on OOP would take it as a trivial example and start with a Watch interface and subclass it. But they never really explain how a Watch consists of a Time and Date, with zero or more Complications and a Face.
If you focus on the compositional relationship you get a lot more mileage out of OOP which is the real revolution over the past 15 years. And the decomposition is how you arrive at the Single Responsibility Principle and Encapsulation. Suddenly you can work only with the set of all Complications, or the Face, or Time or Date without worrying about which Watch you have.
EDIT: typo