45

In The C# Programming Language Krzysztof Cwalina states in an annotation:

we explicitly decided not to add support for multiple inheritance [...] the lack of multiple inheritance forced us to add the concept of interfaces, which in turn are responsible for problems with the evolution of the framework, deeper inheritance hierarchies, and many other problems.

Interfaces are a core concept to OO programming languages. I don't follow the meaning of "forced us to add the concept of interfaces"

Does Krzysztof mean that certain design decisions had to be made regarding the use of interfaces where otherwise mulitple inheritance would be used? Or, does he mean that interface's were introduced to C# because of a lack of multiple inheritance? Can you provide an example?

The_Cthulhu_Kid
  • 1,839
  • 1
  • 31
  • 42
P.Brian.Mackey
  • 43,228
  • 68
  • 238
  • 348
  • 1
    I would imagine they were introduced to combat the lack of multiple inheritance because without them, many patterns would be difficult to adopt. – Mathew Thompson Jan 23 '13 at 14:53
  • 2
    This is much better suited for Programmers, as this is not a practical question. – Esoteric Screen Name Jan 23 '13 at 15:56
  • 4
    I don't think of interfaces as being fundamental to OO programming. Interesting that you do. – Eric Lippert Jan 23 '13 at 19:40
  • @EricLippert - I had not even considered such a thing. Combined with Jon's answer, this comment makes a lot of sense. There are other ways to achieve polymorphism that I had not imagined. – P.Brian.Mackey Jan 25 '13 at 05:04
  • @EricLippert - I find it unnerving that you don't (or didn't in 2013) think of interfaces as being fundamental to OO programming. I am curious if you feel differently now. IMHO, Interfaces are **more fundamental than class inheritance**. OO design methodology is cleaner, if one starts with the concept of `interface`, and adds in `class inheritance` later in the learning process. The benefits of this became especially apparent, once F# showed how to combine "OO with functional programming". Turns out you really want (need?) interfaces to do that well. class inheritance is optional. – ToolmakerSteve Oct 22 '21 at 21:22
  • 3
    @ToolmakerSteve: I don't think of class inheritance as fundamental to OO either. Both interfaces and class inheritance are special cases of nominal subtyping, which is also not fundamental to OO. Think about it this way: are there OO languages without class inheritance? Sure. Are there OO languages without interfaces? Sure. So neither is fundamental. – Eric Lippert Oct 28 '21 at 18:37
  • 1
    @EricLippert - thanks, that makes more sense to me. Given that the context was a discussion of class inheritance, I thought you were suggesting class inheritance was more fundamental vis-a-vis OO. Thinking about it, I concur that interfaces are orthogonal to OO - they are a form of contract. – ToolmakerSteve Oct 28 '21 at 21:25
  • 1
    @ToolmakerSteve: That is exactly right; interfaces are a (poor!) implementation of the concept of a contract, and class inheritance is a mechanism for (1) modeling is-a-kind-of relationships and (2) re-using implementation details. Both support the more fundamental OO concepts of state encapsulated by objects that message each other. – Eric Lippert Nov 01 '21 at 21:50
  • @EricLippert: "... objects that message each other." What do you mean by messaging? Calling accessible methods of an object? Firing and subscribing to events? Or are you referring to the messages of an actor system, for example? In my opinion, calling a public method of an object is very different than sending a message. – Luca Cremonesi Dec 09 '21 at 01:41
  • @LucaCremonesi: I mean any of the above; those are all mechanisms for implementing message passing. In my opinion calling a public method of an object is *exactly* sending a message to it. What's the difference between "x = Math.Sin(3.14)" and sending the message "dear Math object, please send me back your computation of the sine of 3.14, I will wait until the result is available"? I don't see a difference; the "put 3.14 into a register, transfer control, put the answer in another register, copy that register to x..." is just an implementation detail of the message passing system. – Eric Lippert Dec 23 '21 at 17:07
  • 1
    @EricLippert: A real message may be ignored, not received, processed out of order and generally it does not directly produce errors (throw exceptions) on the caller object. In my opinion, it is a very different mechanism of interacting with objects than calling public methods. – Luca Cremonesi Dec 23 '21 at 17:28
  • @LucaCremonesi: I think we're largely in agreement and just differ in a minor matter of semantics. It is a deeply unfortunate historical fact that the industry concept of "OO" is epitomized by the design of the original version of C++ which did not have in-language support for any of the valuable features you mention. But my point is that message passing is not a *mechanism*; it's a fundamental *concept* independent of implementation choice. Function calls are a very weak way to implement that concept and I wish languages that do better would gain traction. – Eric Lippert Dec 23 '21 at 22:21

4 Answers4

25

An interface is simply a base class that has no data members and only defines public abstract methods. For example, this would be an interface in C++:

class IFrobbable {
    public:
    virtual void Frob() = 0;
}

Therefore when MI is available as a language feature you can "implement" interfaces by simply deriving from them (again, C++):

class Widget : public IFrobbable, public IBrappable {
    // ...
}

Multiple inheritance in the general case gives rise to many questions and problems that don't necessarily have a single answer, or even a good one for your particular definition of "good" (dreaded diamond, anyone?). Multiple interface implementation sidesteps most of these problems exactly because the concept of "inheriting" an interface is a very constrained special case of inheriting a full-blown class.

And this is where "forced us to add the concept of interfaces" comes in: you cannot do much OO design when constrained to single inheritance only, for example there are serious issues with not being able to reuse code when code reuse is in fact one of the most common arguments for OO. You have to do something more, and the next step is adding multiple inheritance but only for classes that satisfy the constraints of an interface.

So, I interpret Krzysztof's quote as saying

Multiple inheritance in the general case is a very thorny problem that we could not tackle in a satisfactory manner given real-life constraints on the development of .NET. However, interface inheritance is both much simpler to tackle and of supreme importance in OOP, so we did put that in. But of course interfaces also come with their own set of problems, mainly regarding how the BCL is structured.

Jon
  • 428,835
  • 81
  • 738
  • 806
  • I think it is better to say that each interface is a vtable in the class. Makes it easier to explain how a non-virtual member can implement an interface or how a base member can implement an interface in a derived class. (Also points out that implementing an interface is very different from inheritance) – adrianm Jan 23 '13 at 15:15
  • 5
    @adrianm: The vtable is an implementation detail, if a ubiquitous one. I 'd prefer to stick to abstract concepts. – Jon Jan 23 '13 at 15:17
  • 3
    Hum, you forgot to also mention that Java had already proved that interface inheritance working for most of the market. – behnam Jan 29 '13 at 22:18
  • 1
    @benham Actually, interface inheritance existed and was both commercially successful and proven to the market well before Java's first release to the public. – RBarryYoung Feb 26 '13 at 19:50
11

From Chris Brumme:

There are a number of reasons we don't implement Multiple Implementation Inheritance directly. (As you know, we support Multiple Interface Inheritance).

I think what Krzysztof Cwalina states in the quote is not the concept of interfaces itself, but Multiple interface inheritance as a method of multiple inheritance.

There are several reasons we haven't provided a baked-in, verifiable, CLS-compliant version of multiple implementation inheritance:

  1. Different languages actually have different expectations for how MI works. For example, how conflicts are resolved and whether duplicate bases are merged or redundant. Before we can implement MI in the CLR, we have to do a survey of all the languages, figure out the common concepts, and decide how to express them in a language-neutral manner. We would also have to decide whether MI belongs in the CLS and what this would mean for languages that don't want this concept (presumably VB.NET, for example). Of course, that's the business we are in as a common language runtime, but we haven't got around to doing it for MI yet.

  2. The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation. If we were to add a slightly different construct, like mixins, would that actually be more powerful?

  3. Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places.

daryal
  • 14,643
  • 4
  • 38
  • 54
  • Even more fundamental than those issues is that in a diamond scenario, intermediate-layer classes which derive from a common base must either share the same base-class instance or use separate base-class instances. Sharing the base-class instance will make it difficult or impossible for derived classes to enforce their invariants. Using separate instances will make identity-preserving upcasts and downcasts impossible (since the base-class instance associated with a reference will depend upon the sequences of casts performed on it). In other words, .NET fundamentally violates .NET axioms. – supercat Dec 17 '13 at 22:06
4

I think you should read what Eric Lippert says about Interfaces . He has got his hands dirty so I think he knows better than every one else.

Sometimes there are worse cases and worst cases. You have to choose the less bad one.

Below is a copy of the linked post:

They are there just to make sure that the said functions (in the interface) are implemented in the inheriting class.

Correct. That's a sufficiently awesome benefit to justify the feature. As others have said, an interface is a contractual obligation to implement certain methods, properties and events. The compelling benefit of a statically typed language is that the compiler can verify that a contract which your code relies upon is actually met.

That said, interfaces are a fairly weak way to represent contractual obligations. If you want a stronger and more flexible way to represent contractual obligations, look into the Code Contracts feature that shipped with the last version of Visual Studio.

C# is a great language, but sometime it gives you the feeling that first Microsoft creates the problem(not allowing multiple inheritance) and then provides the solution, which is rather a tedious one.

Well I'm glad you like it.

All complex software designs are a result of weighing conflicting features against each other, and trying to find the "sweet spot" that gives large benefits for small costs. We've learned through painful experience that languages that permit multiple inheritance for the purposes of implementation sharing have relatively small benefits and relatively large costs. Permitting multiple inheritance only on interfaces, which do not share implementation details, gives many of the benefits of multiple inheritance without most of the costs.

Community
  • 1
  • 1
Mahdi Tahsildari
  • 13,065
  • 14
  • 55
  • 94
  • @AppDeveloper Fixed. It wasn't properly marked up, but still a valid link. – Servy Jan 23 '13 at 15:04
  • You probably shouldn't copy the *entire* post. It would be preferable to pick a few choice summaries. – Servy Jan 23 '13 at 15:10
  • Interfaces aren't just there to ensure that a particular class includes a function. Their much more important purpose is to define substitutability relations: a method can demand "something that implements `IEnumerable`", and the compiler will allow other types to be substituted if and only if they implement that interface. – supercat Dec 17 '13 at 21:51
2

I think Cwalina's language is a bit strong, and not entirely accurate regarding the history.

Remember that interfaces were around before C#, so to say "we had to add interfaces to solve problem x" doesn't sound right to me. I think interfaces would have been there by default - they would have had to be.

Also, remember that C# is derived largely from C++. Or, at least, the people involved in creating the C# language would have had very strong backgrounds in C++. Multiple Inheritance was an acknowledged nightmare area in C++. Inheriting from multiple classes which themselves may be derived from commonm base classes, working out which implementation would take precedence etc. I mean, it is a very powerful feature, but can undoubtedly lead to complex code.

I suspect they dropped multiple inheritance from C# because they (the language authors) knew how tangled everything could become and they wanted to avoid that. Bear in mind also that when C# was introduced one of its selling points was its cleanliness (in fairless no cleaner than Java but a lot cleaner than C and C++).

Incidentally, in 10+ years of C# development I have only wished for multiple inheritance once. A UI component which I wanted to inherit both a visual style and some common behaviour. It didn't take me long to realise that what I was intending to do would have been a pretty awful design in any case.

PeteH
  • 2,394
  • 1
  • 20
  • 29