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.
-
Possible duplicate of Expressing interface inheritance in natural language– gnatCommented Apr 27, 2016 at 10:14
-
8Jodrell'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 LippertCommented Apr 27, 2016 at 12:24
-
I have unchecked and left with more confusion.– RajeevCommented Apr 27, 2016 at 12:29
-
18For 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 HarveyCommented Apr 27, 2016 at 16:17
-
3I (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 LippertCommented Apr 27, 2016 at 17:10
|
Show 8 more comments
3 Answers
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".
answered Apr 27, 2016 at 12:32
-
4I 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
javaso this is the right answer, unless the OP meant some otherjava:-)– JodrellCommented Apr 27, 2016 at 15:01 -
5Although 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 ♦Commented Apr 27, 2016 at 16:29
-
6@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! Commented Apr 27, 2016 at 16:31
-
5Why would the Java language specification get the final say here? Language specification often claim things that the "common developer" disagrees with about terminology. Commented Apr 27, 2016 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.) Commented Apr 27, 2016 at 19:01
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.
answered Apr 27, 2016 at 8:32
-
1
-
"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." javaworld.com/article/2073649/core-java/… Commented May 6, 2018 at 2:14
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.
