Should inheritance (of non-interface types) be removed from programming languages?

Question

This is quite a controversial topic, and before you say \"no\", is it really, really needed?

I have been programming for about 10 years, and I can\'t honestly sa

Answer 1

Note that inheritance means it is no longer possible to supply the base class functionality by dependency injection, in order to unit test a derived class in isolation of its parent.

So if you're deadly serious about dependency injection (which I'm not, but I do wonder whether I should be), you can't get much use out of inheritance anyway.

Answer 2

For production code I almost never use inheritance. I go with using interfaces for everything (this helps with testing and improves readability i.e. you can just look at the interface to read the public methods and see what is going on because of well-named methods and class names). Pretty much the only time I would use inheritance would be because a third party library demands it. Using interfaces, I would get the same effect but I would mimic inheritance by using 'delegation'.

For me, not only is this more readable but it is much more testable and also makes refactoring a whole lot easier.

The only time I can think of that I would use inheritance in testing would be to create my own specific TestCases used to differentiate between types of tests I have in my system.

So I probably wouldn't get rid of it but I choose not to use it as much as possible for the reasons mentioned above.

Answer 3

Is inheritance really needed? Depends what you mean by "really". You could go back to punch cards or flicking toggle switches in theory, but it's a terrible way to develop software.

In procedural languages, yes, class inheritance is a definite boon. It gives you a way to elegantly organise your code in certain circumstances. It should not be overused, as any other feature should not be overused.

For example, take the case of digiarnie in this thread. He/she uses interfaces for nearly everything, which is just as bad as (possibly worse than) using lots of inheritance.

Some of his points :

this helps with testing and improves readability

It doesn't do either thing. You never actually test an interface, you always test an object, that is, an instantiation of a class. And having to look at a completely different bit of code helps you understand the structure of a class? I don't think so.

Ditto for deep inheritance hierarchies though. You ideally want to look in one place only.

Using interfaces, I would get the same effect but I would mimic inheritance by using 'delegation'.

Delegation is a very good idea, and should often be used instead of inheritance (for example, the Strategy pattern is all about doing exactly this). But interfaces have zero to do with delegation, because you cannot specify any behaviour at all in an interface.

also makes refactoring a whole lot easier.

Early commitment to interfaces usually makes refactoring harder, not easier, because there are then more places to change. Overusing inheritance early is better (well, less bad) than overusing interfaces, as pulling out delegate classes is easier if the classes being modified do not implement any interfaces. And it's quite often from those delegates than you get useful interfaces.

So overuse of inheritance is a bad thing. Overuse of interfaces is a bad thing. And ideally, a class will neither inherit from anything (except maybe "object" or the language equivalent), nor implement any interfaces. But that doesn't mean either feature should be removed from a language.

Answer 4

Here's a nice view at the topic:

IS-STRICTLY-EQUIVALENT-TO-A by Reg Braithwaite

Answer 5

If there is a framework class that does almost exactly what you want, but a particular function of its interface throws a NotSupported exception or for some other reason you only want to override one method to do something specific to your implementation, it's much easier to write a subclass and override that one method rather than write a brand new class and write pass-throughs for each of the other 27 methods in the class.

Similarly, What about Java, for example, where every object inherits from Object, and therefore automatically has implementations of equals, hashcode, etc. I don't have to re-implement them, and it "just works" when I want to use the object as a key in a hashtable. I don't have to write a default passthrough to a Hashtable.hashcode(Object o) method, which frankly seems like it's moving away from object orientation.

Answer 6

Of course you can write great programs happily without objects and inheritance; functional programmers do it all the time. But let us not be hasty. Anybody interested in this topic should check out the slides from Xavier Leroy's invited lecture about classes vs modules in Objective Caml. Xavier does a beautiful job laying out what inheritance does well and does not do well in the context of different kinds of software evolution.

All languages are Turing-complete, so of course inheritance isn't necessary. But as an argument for the value of inheritance, I present the Smalltalk blue book, especially the Collection hierarchy and the Number hierarchy. I'm very impressed that a skilled specialist can add an entirely new kind of number (or collection) without perturbing the existing system.

I will also remind questioner of the "killer app" for inheritance: the GUI toolkit. A well-designed toolkit (if you can find one) makes it very, very easy to add new kinds of graphical interaction widgets.

Having said all that, I think that inheritance has innate weaknesses (your program logic is smeared out over a large set of classes) and that it should be used rarely and only by skilled professionals. A person graduating with a bachelor's degree in computer science barely knows anything about inheritance---such persons should be permitted to inherit from other classes at need, but should never, ever write code from which other programmers inherit. That job should be reserved for master programmers who really know what they're doing. And they should do it reluctantly!

For an interesting take on solving similar problems using a completely different mechanism, people might want to check out Haskell type classes.