Is-a, extends, 'inherits': What is your preferred term for "inheritance" and why?

A subjective question, 开发者_C百科hence if there are complaints I'll wiki, but I'd like to know what people's takes are on the different terms that are used for inheritance almost interchangeably.

We have "is-a", "extends", "derives", "subclasses" and simply "inherits"

The words we choose have a lot of meaning packed into them. What is your preferred term for "inheritance" and why?

Be compelling!

I most often uses "A subclasses B" (very direct) or "A inherits from B" (modestly more circumlocutory). "extends" is fine in languages where it's a keyword such as Java, but using it for (say) C++ or Python seems to be a bit of a stretch, for some reason. "IS-A" is a relationship constraint that inheritance must respect (Liskov's principle) and holds between instances (left side) and classes (right side) -- so you can say "x IS-A Foo" (when x is an instance of Foo or any subclass of Foo), but "Bar IS-A Foo" (where they're both classes) seems wrong, it would cause confusion in languages where classes are also instances of (meta)classes such as Python.

I like to say derived because it strongly implies the class / subclass relationship, but would be reasonably accurate in the more exotic cases, like multiple inheritance, interface implementation, and mixins.

I have various secondary arguments. For one thing, "parent" and "child" strongly imply a specific structural analogy that may clash with the actual relationship. For another, the entire point is the reuse of both code and also the abstraction itself. If memory was free and we all typed one million words per minute, it still would not be a good idea to copy and paste code, because that would hide the relationship between the various abstractions. Derived makes it clear that what you are doing is sharing at least a part of the abstraction you started with.

I was tought to consider that if you can connect to classes A and B between an "A is a B" (whale is a mammal) relationship, then they are bound by inheritance.

So i prefer IS A

There are differnet terminoligies in different languages.

"is a" suits dynamic languages and relects the chimeric qualities of perl/php/python and javascript objects. Lassie is a Dog, is a Mammal, is a Pet, is a Movie Star is also an asset of MGM.

"extends" suits the declarative, strict typing of nature of Java (and its lack of multiple inheritance!). "Lassie extends Dog", Lassie can walk and bark but cannot star or perform when she is implemneted in Java!

There are two ways to think about inheritance:

is-a : Polymorphism is when an interface is defined by a base class, but the implementation can be provided by an inherited class.

public class Polygon
{
   public abstract int Points();
};

public class Triangle : Polygon
{
  public override int Points() { return 3; }
}

void Foo( Polygon p )
{
  int points = p.Points();
}

main()
{
   Foo( new Triangle() );
}

extends - a way of capturing shared implementation.

public class iTouch
{
    // cool pda features
}

public class iPhone : private iTouch
{
    // phone features
    // cool pda features comes from the base class
}

The preferred terminology usually depends greatly on the language, but I find that most OO developers understand each other regardless of the terms. (That being said, I definitely agree that word choice is important for maximizing effectiveness of communication.)

My preferred terminology is "subclasses" or "extends" for classes, and "implements" for interfaces. (In Objective-C, one "adopts" or "conforms to" a protocol, the inspiration for Java's interfaces.) Often, I use "parent" and "child" to describe the relationship itself.

I find that "is a" works best when contrasting with "has a" (composition), but it doesn't make sense for all forms of inheritance — sometimes, narrowing specificity makes sense, but not always. Similarly, there are times that "derives" just doesn't seem right — many people will understand it as specialization, but not everyone will. (For example, one can derive a proof, derive chemicals via a reaction, etc. Check out a dictionary entry on the word to see the variety of possible meanings, many of which have to do with a set of steps, which sounds more like an algorithm than inheritance.) On a side note, I've found that "base class" and "derived class" are preferred by many academics, but perhaps not as often in industry.

I'll say here that simplicity is a good thing. I'm all for "A Is a B" when referring to a subclass (A) that is obviously an instance of the parent class (B) (A Dog is a Mammal etc). If the relationship isn't that simple, I prefer to simply say "A is a subclass of B".

Class composition clearly makes the idea of "A Is a B" difficult, so there's obviously a time when "A Has a B" or "A Owns a B" is easier to understand.

For the continued sake of simplicity, I prefer to say a class conforms to a protocol, or implements an interface (although I don't program in java much).

The key as far as I'm concerned, is simplicity and ease of communication. If you're working on a project yourself, and will never have to discuss your design or code to anyone else, call it whatever you want. If you're working on a team, establishing the simplest possible standard of communication saves a lot of headache trying to decipher everyone's different slang for OOP patterns.

Here is the terminology that I prefer:

• A inherits from B - This is the simples most precise method.
• A derives from B - This is useful to generally describe cases where A inherits B or from some other class which derives from B.

Here is the terminology that I dislike:

• A extends B - This is not quite accurate because a class can derive from another class, and just do things differently without literally extending it. It is also often used to describe the relationship between interfaces.
• A subclasses B - Inheritance isn't restricted to just classes.
• A is a B - If A inherits from B, it isn't necessarily the same things as a B, unless it can be used legally wherever a B can be used. If the design contract preconditions and postconditions of virtual function aren't properly weakened and strengthened in the new class, the A is not technically a B because it violates the Liskov substitution principle.

I like to kick it old-school and say "A implies B" or "A is less than B". These are not ambiguous like the other terms, i.e. they have precise meanings.

Footnote: I sometimes say "better than" and "worse than" to mean supertype and subtype relations, respectively. I do this to disambiguate this relation when it's not clear that the objects in question are types. I inherited this habit from Edward Kmett.

See here.