extend a class, implement an interface

Posted Aug 11, 2025 10:46 UTC (Mon) by paulj (subscriber, #341)
Parent article: Go and Rust — objects without class

> While inheritance is a core concept in object-oriented programming, it is not necessarily a well-defined concept.

So don't use that term, as such. The better defined concepts are:

* Extension: One class may extend another class
* Implementation: One class may implement a specification/interface.

Note how the term 'extends' naturally encompasses the properties of the extending object having the fields and methods of the class it extends and potentially adding further terms. It's a much more natural, self-explanatory term to use. Implementation also (if slightly weaker) naturally describes what is happening - a class implements a concrete methodology of some other, more abstract, specification or interface.

extend a class, implement an interface

Posted Aug 11, 2025 13:38 UTC (Mon) by Replaced_by_AI (guest, #178731) [Link] (1 responses)

It's valid, but the "inheritance concept" in object-oriented programming is limited to classes/objects usage.

Although an interface can also be "inherited" and "inherit", it's not the same as the OO concept, but the word meaning instead.

extend a class, implement an interface

Posted Aug 11, 2025 14:12 UTC (Mon) by paulj (subscriber, #341) [Link]

Almost immediately after the sentence I quoted from the article, Neil mentions interfaces as something that 'inheritance' might apply to:

> The thing is typically a "class", but sometimes an "interface" or even (in prototype inheritance) an "object" that borrows some behavior and state from some other "prototypical" object.

So I brought in 'implements' as a clarifying term precisely because the article itself refers to interfaces. Given the situations the _article considers_ I think 'extends' and 'implements' are the better terms for those situations (which explicitly includes interfaces). I would agree with Neil that, in general understanding, 'inheritance' is not well defined. And this may well be because general software engineers are just unfamiliar with the original precise definitions in founding use or in the literature - but in such situations, we just need to come up with better terminology (and do a better job of 'guarding' their meaning).

The article also misses out on clarifying the rules of typing and sub-typing. These are well-explored in the literature, and there are some very good "rules" that programmers should be familiar with, that can help them avoid mistakes (and some languages can check for them, in at least some cases, if not all). E.g., Liskov's Substitution Principle. (I see another comment has also made that point).