Your comment doesn't seem to be related to "Inheritance" at all but merely a opinion drawn from your anecdotal experience and hence not generalizable. As a counter-point i have read/written my fair share of hairy OO-code (mostly C++) and i can assure you that while it was a-lot-of-work sometimes (due to the complexity of the codebase itself) it was never "throw-up-my-hands" difficult once i applied some system and method. I hardly ever use a debugger but use tools like Doxygen/Cflow/cscope/etc. to get the static view of class hierarchy/call graph and profiler/printf trace/etc. to get the runtime dynamic call graph. These give me enough insight into the architecture to become productive.

It is also a fact that OOD/OOP has been a enormous success in the real world in structuring "Frameworks" which give you a generic driver skeleton application for free into which you plugin your application specific code using (you guessed it!) "Interface/Implementation Inheritance".

Finally i recommended Bertrand Meyer's OOSC2 book because nobody explains OOD/OOP better then him in a thorough and precise manner which clears almost all of one's doubts.

I really appreciate your comment and it's absolutely true that I have no data. I don't think it's entirely anecdotal though, most newer languages and in case of JS newer paradigms are all strongly pushing against any form of inheritance, so this is an industry-wide change. I'm thinking of Go, Rust and the whole JS ecosystem that tries to write functional code (there might be others).

I wouldn't put "class inheritance" in the same ballpark as "interface implementation", one is sharing code, the other is adopting a protocol. In my statement I was referring strictly to class inheritance for the purpose of code sharing.

Unfortunately it's hard to bring up any meaningful numbers when talking about programming languages.

Define success too: OOP has been used widely, but it's way harder to find numbers representing if the codebase is easier to navigate and maintain versus this new industry trend. Also, there is massive failure with OOP, it's just less documented than the success (look at all the companies that died due to poor software).

And yes, all I can bring is an "industry trend", but the "enormous success" you are talking about in real world is effectively an industry trend too, but of course that's been going on for way longer.

The tools you are talking about sound very interesting, but those are effectively "undoing" the inheritance, isn't that the case? The code should be written for humans, and you seem to be using a tool to literally put all the dynamic calls back into one place so that it's easier to follow.

P.S. I'll check the book

>The tools you are talking about sound very interesting, but those are effectively "undoing" the inheritance, isn't that the case?

Oh, No!

Any system (OO or not) has two views;

1) A static view which gives the structure of the system (which is what we try to find out by browsing the codebase). Eg. class diagrams, ERDs, Sequence diagrams, State diagrams, static call graph etc. My first category of tools help you with this.

2) A dynamic view which gives the runtime call graph and state changes as the code executes. Obviously, this is harder to understand if "dynamic dispatch" of function calls are involved (which is the case in OO inheritance). My second category of tools helps you with this.

Remember, OOP is just another way of architecting Procedural/Imperative code and hence we have the same challenges (and a little extra :-)

I've been going through the book all day long, but I'm not too enthusiastic about it. It focuses so much on the "coding" that it seems to transcend the human aspect of it, that is, there will be developers that are not able to properly split classes, there will be teams, there will be incorrectly shaped boundaries, time constraint and even language limitations.

The book seems to be great at doing an incredible analysis of an OOP language, but it doesn't seem to consider the fact that the human portion of it matters a lot.

Sometimes generalizing the code so that it supports all use-cases is more expensive than just rewriting the part of the code that will change. This statement is what feels my thought as I read through the book. And even in the analysis, it seems to focus on the ideas, but not why (and numbers) that brought to this.

I bring a simple example. I have no idea what this class does:

    class Foo < Bar
    end

I know exactly what this one does:

    class Foo
      def initialize
        @bar = Bar.new
      end
    
      def something
        @bar.something
      end
    
      def whatever
        @bar.whatever
      end
    end

With the tools you described, it makes sense, you can achieve this, but without them, the problem becomes serious.

The "advantage" of the first one is that when Bar changes its public interface, Foo will change too. I don't think this is a good idea. It's nice you have to write less, but whenever a public interface changes, it should break things.

Then again, I definitely didn't write a book or have any numbers. I'll keep going through the book, but it's been quite frustrating. Very academic, so I have to skim chunks of it.

It is great that you are looking into OOSC2. Yes Meyer is somewhat difficult to read since he is so thorough, precise and detail-oriented that it can become tedious at times. Take your time going through the book to get the big picture of his OO design/implementation arguments rather than the details of the Eiffel language (not necessary during the first pass). It is a huge book so skip topics as needed to focus on the essential concepts.

You should also look into Meyer's "Design By Contract" technique for writing "correct" OO and other-paradigm programs. This is of great value in real-world programming.

PS: You might also find another Meyer's book Agile! The Good, the Hype and the Ugly quite instructive - https://learning.acm.org/techtalks/agile