views:

275

answers:

9

A subjective question, 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!

+1  A: 

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

Tom
Trouble is, that doesn't always work. Often, classes represent abstract ideas and entities that don't fit into a nice metaphor. I use "is a" on occasions when appropriate (mostly in contrast to "has a" for composition) but I don't consider it a broadly-applicable term of choice.
Quinn Taylor
+3  A: 

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.

Alex Martelli
+3  A: 

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.

DigitalRoss
Good argument — I like "extends" for many of the same reasons. Classes are primarily about encapsulating behavior with data, so it generally makes the most sense to me.
Quinn Taylor
+1  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!

James Anderson
Good points, but in your example, "is a" could just as easily represent composition, as opposed to inheritance. (In fact, I'd argue that using multiple inheritance to satisfy all these constraints is probably poor design.) Similarly, you could say something "extends" more than one other thing, although I agree that it fits best with single inheritance.
Quinn Taylor
+1  A: 

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
}
Phillip Ngan
+1  A: 

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.
cdiggins
However, one could make the argument that your preferred terminology is vague. When you're dealing with 2 classes, "subclass" and "superclass" are the right terms. You have good points about "extends" and "is a" — they don't quite fit. In the same vein, "inherits" is odd because it's poor grammar; generally, one would say "inherits from", because it doesn't actually inherit a B, it inherits methods and variables from B. (Okay, enough pedantic hair splitting.)
Quinn Taylor
Changed "inherits" to "inherits from".
cdiggins
+1  A: 

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.

Quinn Taylor
+1  A: 

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.

alesplin
A: 

I like to kick it old-school and say "A implies B". It's not ambiguous like the other terms, and has a precise meaning.

See here.

Apocalisp