Why are Super-class and Sub-class reversed?

Question

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.

W

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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).

Answer 5

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.

Answer 6

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?