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

a lot of the time I find myself choosing a base class over an interface just because I have some standard functionality. in C#, I can now use extension methods to achieve that, but it still doesn't achieve the same thing for several situations.

Answer 2

No. Sometimes you need inheritance. And for those times where you don't -- don't use it. You can always "just" use interfaces (in languages that have them) and ADPs without data work like interfaces in those languages that don't have them. But I see no reason to remove what is sometimes a necessary feature just because you feel it isn't always needed.

Answer 3

The question is, "Should inheritance (of non-interface types) be removed from programming languages?"

I say, "No", as it will break a hell of a lot of existing code.

That aside, should you use inheritance, other than inheritance of interfaces? I'm predominantly a C++ programmer and I follow a strict object model of multiple inheritance of interfaces followed by a chain of single inheritance of classes. The concrete classes are a "secret" of a component and it's friends, so what goes on there is nobodies business.

To help implement interfaces, I use template mixins. This allows the interface designer to provide snippets of code to help implement the interface for common scenarios. As a component developer I feel like I can go mixin shopping to get the reusable bits without being encumbered by how the interface designer thought I should build my class.

Having said that, the mixin paradigm is pretty much unique to C++. Without this, I expect that inheritance is very attractive to the pragmatic programmer.

Answer 4

Inheritance can be rather useful in situations where your base class has a number of methods with the same implementation for each derived class, to save every single derived class from having to implement boiler-plate code. Take the .NET Stream class for example which defines the following methods:

public virtual int Read(byte[] buffer, int index, int count)
{
}

public int ReadByte()
{
    // note: this is only an approximation to the real implementation
    var buffer = new byte[1];
    if (this.Read(buffer, 0, 1) == 1)
    {
        return buffer[0];
    }

    return -1;
}

Because inheritance is available the base class can implement the ReadByte method for all implementations without them having to worry about it. There are a number of other methods like this on the class which have default or fixed implementations. So in this type of situation it's a very valuable thing to have, compared with an interface where your options are either to make everyone re-implement everything, or to create a StreamUtil type class which they can call (yuk!).

To clarify, with inheritance all I need to write to create a DerivedStream class is something like:

public class DerivedStream : Stream
{
    public override int Read(byte[] buffer, int index, int count)
    {
        // my read implementation
    }
}

Whereas if we're using interfaces and a default implementation of the methods in StreamUtil I have to write a bunch more code:

public class DerivedStream : IStream
{
    public int Read(byte[] buffer, int index, int count)
    {
        // my read implementation
    }

    public int ReadByte()
    {
        return StreamUtil.ReadByte(this);
    }
}

}

So it's not a huge amount more code, but multiply this by a few more methods on the class and it's just unnecessary boiler plate stuff which the compiler could handle instead. Why make things more painful to implement than necessary? I don't think inheritance is the be-all and end-all, but it can be very useful when used correctly.

Answer 5

I believe a better mechanism for code re-use which is sometimes achieved through inheritance are traits. Check this link (pdf) for a great discussion on this, including the distinction between traits and mixins, and why traits are favored.

There's some research that introduces traits into C# (pdf).

Perl has traits through Moose::Roles. Scala traits are like mixins, as in Ruby.

Answer 6

I blogged about this as a wacky idea a while ago.

I don't think it should be removed, but I think classes should be sealed by default to discourage inheritance when it's not appropriate. It's a powerful tool to have available, but it's like a chain-saw - you really don't want to use it unless it's the perfect tool for the job. Otherwise you might start losing limbs.

The are potential language features such as mix-ins which would make it easier to live without, IMO.