If inheritance is not available, the problem doesn't exist.
Same goes for immutability, in the end our tools are tuning for the lowest performers
The basic idea behind "Inheritance" is simple and can be understood by all programmers. Its realization through various language features and their combinations is what makes it somewhat confusing. Once explained and practiced with discipline, inheritance is very powerful.
See my other comment: https://news.ycombinator.com/item?id=36428689
> The basic idea behind "Inheritance" is simple and can be understood by all programmers.
Not just by programmers. Just about everyone says "give me something like this, but with the following changed."
That's the basic premise of inheritance and it clicks with everyone.
I think the fact that when listing languages sorted by popularity, you can draw a line in the list, and everything above that line supports traditional OO while everything below that line provides band aids for it says a lot about how much OO clicks with programmers.
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 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
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 :-)
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
class Foo
def initialize
@bar = Bar.new
end
def something
@bar.something
end
def whatever
@bar.whatever
end
end
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.
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