Why are Super-class and Sub-class reversed?

In set theory, a set is a superset if it contains everything in the original set and possibly more. A subset however is does not contain everything of the initial set.

With that in mind, in most object-oriented programming languages (I'm thinking Objective-C but I know the same is true for Java and others), the parent class is called the super class, and any class which inherits from the super is called a subclass.

Isn't this backwards? A subclass inherits things like all instance variables and methods from its superclass, thus it "contai开发者_如何学Pythonns" everything from the parent, plus whatever is added in the subclass. Is this just a naming mistake or was this intentional, and if so why?

A superclass defines a class that has a larger set of possible values as members. A subclass restricts the items that can be part of its class, so it defines a smaller set of possible members.

The set of possible members of a superclass is a superset of the set of possible members of a subclass of that superclass.

Greg is correct. Two things to consider that might make it more clear:

1. the propertes and methods are not relevant to the sub/super relationship in terms of set theory:

   • the properties and methods defined by a subclass may extend beyond those provided by its superclass (and in fact, they often do), but instances of the subclass are still members of the set of instances of the superclass
   • in other words, the sub/super relationship is not defined by the propertes and methods, but by the instance-level semantics intended by the naming of the classes

2. Taxomony example:

   • the set of all People is larger than the set of all Programmers
   • the set People is, in fact, a superset of the set Programmers
   • the set Programmers is a subset of the set People

so in OOP terms, People would be a superclass and Programmer would be a subclass. Every Programmer is a person, but not every person is a Programmer. Hence superclass and subclass. The fact that the Programmer class may have super powers beyond the ken of mortal men does not change the class-relationship (is-a) semantics.

Greg's answer is correct. Here's an explanation by example:

You have a base class Base. You have two derived classes DerivedA and DerivedB. Every instance of DerivedA is also an instance of Base. Likewise, every DerivedB is also a Base. But, a DerivedA is not a DerivedB and vice versa. So, if you were to draw a Venn diagram of the universe of all possible objects, you'd get:

    ________________________
   /                        \
  /          Base            \
 /    ______        ______    \
|    /      \      /      \    |
|   /        \    /        \   |
|  | DerivedA |  | DerivedB |  |
|   \        /    \        /   |
|    \______/      \______/    |
 \                            /
  \                          /
   \________________________/

In other words, every object in the set of DerivedA objects is also in the set of Base objects. Likewise for DerivedB. So Base is indeed the superset of both DerivedA and DerivedB. Hence, it is the "superclass".

Probably for the same reason that stacks grow down (bottom at the top), trees grow down (root at the top) and 2D graphics systems are almost always quadrant IV (0,0 in upper left).

The subclass has all the [members] of its superclass [and more]. Isn't this backwards?

This issue crops up all over programming languages, and it always makes my head hurt. (Subtyping especially.)

Here are the rules:

• When you are considering obejcts, the subclass/child/subtype has more methods and members. It can be used in more contexts. This seems counterintuitive.

• When you are considering contexts, or interfaces, or arguments, roles are reversed. For example, a method expecting an argument of the supertype/parent/superclass can accept more arguments than a method expecting an argument of the subtype.

Which one is on top depends entirely on whether you think objects are primary or whether you think contexts expecting objects are primary. I have studied this subject for almost 15 years and still my intuition betrays me.

If a class declaration is considered as a specification, then the superclass specification is satisifed by more objects, and the subclass specification is satisfied by fewer objects. I believe this is the reason for the nomenclature. (It is a little clearer if you talk about subtypes and supertypes—a subtype is inhabited by fewer values than its supertype, because every value of the subtype is also a value of the supertype, and the supertype is likely inhabited by additional values that are not members of the subtype.)

Did I mention that the whole topic makes my head hurt?

I sidestep the whole super/sub class issue and refer to them as "derived" and "parent" class.

Yes, but if you think of your diagram as a topographic map, the subclasses have higher altitudes than the superclass. Hence the confusion.

Another way of looking at this is that the superclass is akin to the leading digit in a number (to make this a programming language friendly analogy, we'll say a floating point number). As the number acquires more digits, each new digit "inherits" all the digits that precede it. Similarly, as the subclass gains more methods, it inherits the list of superclasses, in the order in which they were named, that precede it.

Hope this helps.