34

If my class implements an interface then can I say that I'm following inheritance? I know that when a class extends another class then it's inheritance.

Benjamin Hodgson
  • 4,488
  • 2
  • 25
  • 34
Rajeev
  • 525
  • 1
  • 5
  • 9
  • Possible duplicate of [Expressing interface inheritance in natural language](http://programmers.stackexchange.com/questions/284841/expressing-interface-inheritance-in-natural-language) – gnat Apr 27 '16 at 10:14
  • 7
    Jodrell's comment is simply wrong. Implementing an interface is indeed inheritance, and inheriting one interface from another is inheritance. How do we know? By defining the word we're using. **Inheritance** is the property that the inheritable members of one type are also members of another type. By this definition, plainly a class which implements an interface has inherited all the interface's methods; just look at the class and the interface and you'll find that in a correct program, they have the same members. – Eric Lippert Apr 27 '16 at 12:24
  • I have unchecked and left with more confusion. – Rajeev Apr 27 '16 at 12:29
  • @EricLippert your comment (and answer) will look funny if OP changes their mind and decides to accept your answer – gnat Apr 27 '16 at 12:37
  • What does it mean Mr. gnat and what I'm supposed to do now? Should I have to say both versions to my superior/interviewer/whoever it may be ,If I'm asked this question? – Rajeev Apr 27 '16 at 12:43
  • @DocBrown, okay, I was wrong, inheritance means different things, depending on context. In this case `java`, where inheritance still means different things. – Jodrell Apr 27 '16 at 15:12
  • Yes indeed implementing an interface is inheritance. It is only because of interfaces that we can do multiple inheritance in Java. – Faizan Akram Dar Apr 27 '16 at 15:30
  • 18
    For what it's worth, I think you're spending a lot of time on a word definition that isn't going to yield you much benefit. At the end of the day, we all know what implementing an interface means, and whether it is considered "inheritance" is largely immaterial to your daily work. – Robert Harvey Apr 27 '16 at 16:17
  • 3
    I (mostly) agree with Robert. I think there is real value in understanding the precise technical meanings of jargon words as they are used in various contexts. But Robert is right that it is of far greater benefit to understand the practical impact! How can you use inheritance to make your code safer? More testable? More reusable? More flexible? And so on. Knowing that members of base types are also members of derived types is great, but it is better still to know how to use it effectively. – Eric Lippert Apr 27 '16 at 17:10
  • Good thing that we know Java interfaces are just that, interfaces, while abstract classes are allowed to have code. [oh, wait, that is not true](https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html). Nevermind some of the answers, this _question_ is wrong. –  Apr 27 '16 at 18:42
  • This is just semantics. It's much more important to understand the practical implications of interface implementation vs. subclassing. – jpmc26 Apr 28 '16 at 07:21
  • @EricLippert The trouble with precisely understanding the meaning of a technical term is that other people don't, and may use the term differently, which may end up misleading you. The poster child for this is the term "static initialization" in C++, which in the C++ standard means "things initialized with constants", but in common C++ parlance means "things initialized with dynamic code at program startup". – Sebastian Redl Dec 06 '17 at 15:02
  • @SebastianRedl: Indeed. My poster child for this is "strongly typed", which has a dozen different meanings many of which contradict each other. – Eric Lippert Dec 06 '17 at 15:18

3 Answers3

78

UPDATE: I've revised this answer. A number of good points were raised in the comments that deserved calling out.

If my class implements an interface then can I say that I'm following inheritance?

It is not entirely clear what you mean by "following inheritance". Let's ask a slightly different question?

What is inheritance?

  • When members of one type X are considered to be members of another type Y, those members of Y are inherited from X.
  • There is an inheritance relationship between some types; that is, for some types X and Y we say "Y inherits from X".

These are subtly different. That is unfortunate because it is confusing.

What confusions typically arise from this subtle distinction?

Confusion may arise because people think of inheritance as a mechanism for sharing implementation details. Though it is such a mechanism, that mechanism works by sharing members. Those members need not have implementations! As we will see, they can be abstract.

I personally would be happier if the Java and C# specifications used a word other than "inherits" to describe the relationship between interface methods and classes, to avoid this confusion. But they do not, and we have to reason from the specifications, not against them.

In Java, are interface members inherited by classes which implement them?

Yes, some are. See the Java specification section 8.4.8, which I quote here for your convenience.

A class C inherits from its direct superclass and direct superinterfaces all abstract and default methods m for which all of the following are true: [...]

If you say that a class implements an interface then the class inherits the abstract and default methods of that interface. (Of course I have omitted the conditions which follow; see the specification for details. In particular, a class which implements a member of an interface is not considered to have inherited that member. Again, is this confusing? Yes.)

Do we typically say in Java that a class inherits from an interface?

Typically we would say that a class implements an interface. As noted above, a class may inherit members from an interface, and yet still not be said to inherit from the interface. Which is confusing, yes.

Does this subtle distinction matter in day-to-day work?

Typically not. This sort of narrow parsing of the specification is more useful to compiler writers than line of business developers. Its more important to understand when to use an interface than it is to get a precise definition of "inherits from".

Eric Lippert
  • 45,799
  • 22
  • 87
  • 126
  • 3
    Thanks Mr. Eric. I have unchecked the Kilian Foth answer which I accepted earlier. – Rajeev Apr 27 '16 at 12:35
  • 4
    I can't argue with a canonical reference. When specifications differ, as they necessarily do, simple terms become semantically overloaded and ambiguous out of context. The question is tagged with `java` so this is the right answer, unless the OP meant some other `java` :-) – Jodrell Apr 27 '16 at 15:01
  • 1
    @Jodrell: I am somewhat confused by your comment. Which "differing" specification are you referring to? – Eric Lippert Apr 27 '16 at 15:32
  • specifications that define a meaning for inheritance. – Jodrell Apr 27 '16 at 15:34
  • 1
    @Jodrell: Are you perhaps thinking of the C# specification? The C# spec states that classes inherit members from base classes, that structs, enums and delegates inherit from their respective base types, and that interfaces inherit from each other. But unlike Java, the C# spec does not say that classes inherit members from interfaces. – Eric Lippert Apr 27 '16 at 15:35
  • 1
    @Jodrell: Or perhaps you are thinking of the C++ specification, which says "*members of a base class are also considered to be members of the derived class. The base class members are said to be inherited by the derived class.*" Since C++ does not have interfaces, it also has no text in the specification about interface inheritance. – Eric Lippert Apr 27 '16 at 15:37
  • 1
    C# is the one I'm most recently familiar with but I keep meaning to read more of your recent blog series so perhaps soon I'll be considering the F# specification, I don't know if inheritance applies there though. – Jodrell Apr 27 '16 at 15:40
  • 1
    @Jodrell: The F# specification is unfortunately somewhat incoherent on the subject. It does not clearly define inheritance, and where it tries to it says "An `inherit` declaration specifies that the type being defined is an extension of an existing type. " This conflates the inheritance mechanism for adding a member with the extension mechanism, but I do not know enough about the design of F# to know if this conflation is deliberate or accidental. – Eric Lippert Apr 27 '16 at 15:53
  • 5
    Although the question is tagged with Java, I find it problematic to cite a language specification for a generic term. Many languages have interfaces and their language specs may use a different term, so using a Java-specific term may be confusing when talking to developers who use X-Lang. – Thomas Owens Apr 27 '16 at 16:29
  • 5
    @ThomasOwens: I agree that this scenario is common and I completely disagree with your conclusion. The solution to the communication problem you describe is **educate everyone involved as to the precise meanings of the words in the relevant context**. Specifications exist to provide this clarity; use them! – Eric Lippert Apr 27 '16 at 16:31
  • 1
    @EricLippert That makes sense, once you are talking about a specific language. UML uses the terminology "realizes an interface" and a different notation than class inheritance - if I made a UML diagram showing realization, that would turn into an interface and a class in Java or a class containing 1+ pure virtual functions and a concrete class in C++. How should I refer to it in this case? Does it vary if I know that my implementation language is Java or should I use the UML terminology when referring to the diagram and the Java terminology when referring to the code? – Thomas Owens Apr 27 '16 at 16:44
  • 2
    @ThomasOwens: Your question is "how do I deal with ambiguity in communication?" and I will repeat my answer. If you think that the person you are communicating with might be confused then you refer them to the specification that defines the words you are using. – Eric Lippert Apr 27 '16 at 16:48
  • @ThomasOwens FWIW very similar question has been asked here in language agnostic context and per my reading it supports that interface inheritance is legitimate concept ([Explanation of the definition of interface inheritance as described in GoF book](http://programmers.stackexchange.com/q/207126/31260)) – gnat Apr 27 '16 at 16:56
  • 5
    Why would the Java language specification get the final say here? Language specification often claim things that the "common developer" disagrees with about terminology. – Benjamin Gruenbaum Apr 27 '16 at 18:01
  • 5
    @BenjaminGruenbaum: Don't I know it. Those developers are wrong, and they often take it upon themselves to "educate" others as to their wrong beliefs. You would not believe the number of programming language books I've had to fix because the authors had some completely crazy beliefs about VB, C#, JavaScript, etc, that were in no way correct. (Jon Skeet was not among them; C# In Depth was correct from the start! Never have I made so few comments on a book and still gotten paid.) – Eric Lippert Apr 27 '16 at 19:01
  • 3
    @BenjaminGruenbaum: Now as for your actual question, indeed, why *should* the designers of the language have the final say about the terminology and its precise definition? Similarly we could ask why it is that J K Rowling has the final say about the events in the Harry Potter books, merely because she spent years of her life creating that work and keeping it consistent. If I think that something else should have happened at Hogwarts, surely my opinion is every bit as valid as hers, right? – Eric Lippert Apr 27 '16 at 19:07
  • I'm not convinced that quote even applies to general inheritance as the word is usually used in coding EXCEPT that it points up the one case where implementing an interface is truly inheriting--default methods. I would certainly not say I was inheriting from an interface except when it comes to default methods and possibly abstract methods (Since you are truly inheriting the responsibility to implement these methods). For normal method definitions though I'd really look askance at someone who used the word inherit over implement--I'd probably even consider them plain old wrong in an interview. – Bill K Apr 27 '16 at 22:08
  • Strtictly speaking, java does have multiple inheritance, but only single direct super classes. =) – null Apr 27 '16 at 23:40
  • @EricLippert As I said it's used correctly in that quote but really only because of Default Methods If you were to say a class inherited from an interface, you'd only be referring to default methods--not normal method definitions. You'd never use the term with java 7 unless you were to say it "inherited" the responsibility to implement an abstract method which is really not the "Class Inheritance" concept we're discussing. If you were to say that a class implementing an abstract interface inherited it, you'd be straight out wrong (and that's not what the quote in this answer says). – Bill K Apr 28 '16 at 02:46
  • @BillK: Now, I am not saying that a class which implements an abstract interface "inherits the interface". I am saying what the specification says: that abstract members of superinterfaces are **inherited by classes**. Again, this is the definition of inheritance in Java, C++ and C#: that *members* of base types are inherited by types which derive from or implement them. – Eric Lippert Apr 28 '16 at 03:05
  • @EricLippert It does inherit the abstract method. (If the interface has an abstract method, the abstract class will too). If your class IMPLEMENTS the method it's no longer inherited, it's implemented like with all the non-abstract class definitions. that's why I said it's not really the same concept as the class inheritance that the Original question was referring to. Class Inheritance as per the original question would, for example, absolutely not apply to the concept of implementing a java 7 interface in a concrete (non-abstract) class. – Bill K Apr 28 '16 at 03:16
  • @BillK: I see your point now; you are correct to note that if a class has a method whose signature is compatible with the signature of the abstract interface method then that method is not considered to be inherited. – Eric Lippert Apr 28 '16 at 03:21
  • With inheritance you would override a method. This is a key part, you change the way it works. With an interface you tend not to override (although default methods are an exception)--you tend to implement them. That said, what I really meant about the interview is if someone used the terminology inherits in relation to a class implementing an interface without mentioning these cases, they would certainly not understand the basic terminology and it's general usage in team communication. – Bill K Apr 28 '16 at 03:27
  • What about "marker" interfaces in .net that have no members...... – Ian Apr 28 '16 at 14:37
  • @ian it would not be inheritance. Only default methods (because they have an implementation) are REALLY inherited (With the slight and strange exception of inheriting the requirement to implement an abstract method). In general I would just say be very careful saying interfaces use inheritance to anyone who might be evaluating your programming skills for any reason.. moreover be very specific if you choose to use that wording. An extremely valid and useful test question would be "Show me examples of inheritance" looking for someone to incorrectly mention interfaces. – Bill K Apr 28 '16 at 16:13
  • By the way, with the updates I think this is a fantastic answer. – Bill K Apr 28 '16 at 16:17
  • I've been thinking about what bothers me so much about the terminology around inheriting abstract interface methods into abstract classes and it's that we are using the unqualified word "Inheritance". It seems much cleaner if we clearly specify the two kinds of "Inheritance", interface and class. The two terms cross over slightly in that a class can inherit a default method from an interface using "class inheritance" and a class can inherit an abstract method requirement from an interface using "Interface Inheritance". (Those two exceptions being the answer to this question). – Bill K Apr 28 '16 at 17:15
  • Once you look at it that way, it's pretty clear that pre java-8 interfaces had nothing to do with the common usage of the term "Inheritance" (which is class inheritance). This is where most java programmers have an initial negative reaction to this answer... we're old-school and not used to these new-fangled functional constructs. – Bill K Apr 28 '16 at 17:18
27

Inheritance means writing a new subclass for a superclass. Writing a new class against an interface is implementing that interface. (And writing a new interface based on an old one is extending that interface.)

The only correct term that applies to all three possibilities is subtyping. Not every subtype is a subclass.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 1
    [GoF book](http://programmers.stackexchange.com/q/207126/31260 "discussed here") seem to consider interface inheritance appropriate term to describe subtyping (Section 1.6 Class versus Interface Inheritance) – gnat Apr 27 '16 at 17:10
  • "I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. He explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible." https://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html – ricardoramos May 06 '18 at 02:14
1

With subclasses, you

  • inherit state of the superclass (all instance variables, whether you see them or not)
  • inherit actual implementations (all non-abstract methods)

With interfaces, you fullfill a contract by implementing the declared methods.

That's the classical way to look at it. Now with Java 8 the interfaces become a mixture:

  • you still don't inherit state (as interfaces still don't have instance variables)
  • you now can inherit default implementations from the interface

Would implementing an interface whose methods all have default implementations still count as 'implement', or rather as extension? I couldn't tell. As this case is rather far-fetched (this actually enabled stateless multi-inheritance), I'd still use 'inheritance' only with subclasses.

Peter Walser
  • 494
  • 3
  • 7