An eye opener in respect to this was Sean Parent's excellent talk "Inheritance Is The Base Class of Evil" at GoingNative 2013 [1].
I recommend a study of Bertrand Meyer's OOSC2 and language Eiffel - https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...
Not necessarily; if they are strongly coupled related concepts within the same module then it is perfectly fine (eg. private inheritance in C++). Here you are basically structuring for code reuse and not is-a relationship.
>inheritance as a means to leverage polymorphism is good.
This is the "standard" idea of inheritance i.e. sub-typing using Liskov Substitution Principle.
> Polymorphic classes can still share code, but this should be done using composition.
Not necessarily as a combination of the above two should make clear.
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
At least for business applications, you want to keep your behaviour and state separate. And people following OOP dogmatically will (ab)use encapsulation for use-cases where your data should be transparent.
Contrast this to interfaces, which are essentially composable specifications on code-level (and I absolutely love that Java uses interfaces to describe anonymous classes due to the power it gives you for documentation and specification).
Because, yes, sharing state among classes for code reuse, is fundamentally evil... How dare you want to couple state and logic?
Almost like every single UI framework in every mainstream language has converged upon OO as the best way to model the problem at hand... GTk even invented a similar type system to what was mentioned in this PDF just to give C OOP constructs... Now witness as the Rust language has failed to produce a compelling UI/widgeting framework or paradigm, and the best ones out there are Qt-based or GTk-bindings (letting C hilariously handle the OOP for Rust).
Right.
By any measure OOD/OOP has been enormously successful in the real world and hence it is annoying to see blanket statements like "OOD/OOP/Inheritance/etc. is bad" on HN (i expected better). It is one thing to discuss cautions/caveats/different approaches but to dismiss the whole thing is quite silly. Hence my attempt at edification of the readers :-)
I feel strongly that most of the people who think OOP was bad are people who have only ever experienced C++/C#/Java or some even weaker instantiation of OOP.
What do you suppose you're writing when you implement a (micro)service? It's nothing different than an object -- some implementation whose details you don't need to care about when you use it, which details can be changed at any time without disturbing clients (modulo idiocy), and an interface that you use to communicate with it via messages.
And don't even get me started on the OO vs. Functional nonsense...
The other early major OO language was obviously Smalltalk which focused on message passing.
Both C++ and Java were majorly influenced by Simula, while more dynamic languages take on aspects of Smalltalk.
Not only their authors are on the record saying so, Java EE is inspired in an Objective-C framework (Distributed Objects Everywhere), and Hotspot is the evolution of Strongtalk JIT.
Can you really claim as Smalltalk inspired a language without an easy to use DoesNotUderstand? That's pretty much the basis for first class messages and transparent delegation.
Also: https://www.youtube.com/watch?v=ccRtIdlTqlU
edit: you could say that the JVM itself is more explicitly smalltalk-inspired as, AFAIK, has closer to fist class messaging support, but this power is hidden to the typical java program under a more interface oriented design. To reach the full power you have to escape form java into the meta-level via introspection.
https://cs.gmu.edu/~sean/stuff/java-objc.html
The C++ like syntax was to make it more marketable.
Java, like Smalltalk and Objective-C, and others in Xerox linage, is a full stack experience, naturally one cannot dissociate the language from the JVM, that is programming with one arm tied behind the back. Language and platform were designed to work together.
As for doesNotUndertstand, for some limited use cases you would use dynamic proxies,
https://docs.oracle.com/javase/8/docs/technotes/guides/refle...
Tutorial is for Java 8, but java.lang.reflect.Proxy exists since Java 3 (1.3).
And as for reaching out to JVM low level stuff, there is invokedynamic, JVM version of .NET DLR.
Also this meta-level programming is quite common in Smalltalk, when playing around with metaclasses, and Smalltalk APIs for the VM.
I'm not saying to never use classes. I just got really confused about them being pushed as one of the dominant forms of code-reuse.
const dog = new Dog
dog.woof()
Why thankfully?
Some solutions are a natural fit for a class hierarchy. Having to hack in workarounds using traits or receivers is, like any band-aid, ugly as hell.
Maybe. What I've seen online is that there is a sizable chunk of people who think that the concept of inheritance is causing more harm than good overall. I don't see many adding the qualifier "for code sharing".
> These languages make it hard to do inheritance for exactly that reason.
It makes those languages a poor fit for some problem domains, like GUIs, for example. Or games. Or many enterprise systems.
Which is why I am wondering why someone would be thankful that creating programs in certain very popular domains was made more difficult than the alternatives.
Now witness as Rust struggles to produce a compelling widgeting environment that isn't Qt or GTk bindings to other languages which support OO constructs. Witness as apparently creating a "Rust-friendly" OO paradigm or framework is an ongoing academic endeavor, because of this...
Believe it or not, for some domains, object-orientation is the right tool for the job... as some problems are just inherently modeled better with such a paradigm, and are able to take advantage of what it has to offer (encapsulation, polymorphism, inheritance).