IS-A Is Inheritance

Before You Start

Check each box you can do from memory. A box you cannot check yet is not a problem; it points you to a quick refresher, not a grade.

• I can write a class declaration using extends and explain what the subclass inherits.
• I can write a class declaration using implements and name the obligation it creates.
• I can identify a HAS-A relationship from a field declaration in a class body.

Try This First

Classify each relationship as IS-A or HAS-A:

// (a)
class Engine { ... }
class Car { private Engine engine; ... }

// (b)
class Dog extends Animal { ... }

// (c)
class TeamComparator implements Comparator<Player> { ... }

What You Need To Walk In With

The Insight: IS-A in Java is marked by a keyword: extends (class inheritance) or implements (interface implementation). HAS-A is marked by a field declaration. These are structural relationships written in the source code, not interpretations. The keyword rule is unambiguous: find extends or implements in the class declaration, and you have IS-A. Find a field of another class type, and you have HAS-A.

Notice that extends and implements serve the same IS-A purpose but for different kinds of types: extends names exactly one parent class, while implements can name one or more interfaces, and both appear in the class declaration header as explicit, keyword-marked declarations. The third relationship worth keeping distinct is pure usage: when a class mentions another type only inside a method body (as a parameter type or local variable), that is association, sometimes called “uses-A.” It does not appear in the class header at all, and it does not change what the class IS.

You can: identify the IS-A relationships in any class declaration by scanning for extends/implements; identify HAS-A by scanning fields; recognize that a compareTo method is the fulfillment of an IS-A contract, not evidence of a new field-based relationship; and apply both rules to the F19 Lab 1 classes without hesitation.

How It Works

The keyword rule

Both extends and implements establish IS-A because both grant substitutability: wherever the parent type or interface is expected, the child or implementing class is accepted.

What IS-A provides: substitutability

The key consequence of IS-A is that code written for the parent type accepts objects of the subtype without modification. This is the Liskov substitution principle: if S IS-A T, then a T variable can hold an S reference, and any operation valid on T is valid on the actual S object at runtime.

Animal a = new Dog();     // Dog IS-A Animal: valid
Comparator<Player> c = new TeamComparator();   // IS-A Comparator<Player>: valid

HAS-A does not provide this. A Car is not substitutable for an Engine just because it contains one.

F19 Lab 1: IS-A and HAS-A side by side

From F19 Lab 1:

IS-A relationships:
  Player implements Comparable<Player>
  TeamComparator implements Comparator<Player>
  PositionComparator implements Comparator<Player>
  GamesPlayedComparator implements Comparator<Player>

HAS-A relationships:
  Player HAS-A team (String)
  Player HAS-A position (Position enum)
  Player HAS-A gamesPlayed (int)
  Team HAS-A name (String)

The lab uses IS-A exclusively for interface implementation, not for class-to-class extension. This is intentional: composition is the primary structural tool; inheritance is used only to satisfy interface contracts.

Worked Example: Predict Then Check

Label each line as IS-A or HAS-A:

public class Player implements Comparable<Player>
{
    private String lastName;        // (a)
    private Position position;      // (b)
    private Team team;              // (c)

    @Override
    public int compareTo(final Player other) { ... }  // (d): what relationship does this implement?
}

Quick check

Common Misconceptions

Misconception 1: treating implements Comparable<T> as HAS-A

Wrong mental model: “Player HAS-A compareTo method, so the relationship with Comparable<Player> is HAS-A.”

Why it breaks: HAS-A describes fields, not methods. implements Comparable<Player> is the IS-A declaration: Player IS-A Comparable<Player>. The fact that Player supplies a compareTo method is how the IS-A contract is fulfilled, not evidence of HAS-A.

How to correct: Look at the class header. implements Comparable<Player> is there. The keyword implements marks IS-A, regardless of what the implementation consists of.

Source: JLS §8.1.5.

Quick check

Misconception 2: treating a method parameter or local variable type as establishing IS-A

Wrong mental model: “Arrays.sort(nflPlayers, new TeamComparator()) means the main class IS-A Comparator because it uses one.”

Why it breaks: Using a type as a method argument or return type is an association: a “uses” relationship, not IS-A and not HAS-A. IS-A requires extends or implements in the class declaration. Association is transient; it does not change what the class IS.

How to correct: Restrict IS-A claims to class declarations. Look for extends/implements in the class header, not in method bodies.

Formal Definition and Interface Contract

From JLS §8.1.4 (Superclasses):

The extends clause specifies the superclass of a class. [...] The subclass inherits from the superclass all public and protected members.

From JLS §8.1.5 (Superinterfaces):

The implements clause specifies all the interfaces implemented by a class. [...] A class implements all the interfaces named in its implements clause.

Liskov substitution principle: if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.

Mental Model

Think of IS-A as a membership card: class Dog extends Animal gives every Dog object an Animal membership card. Any club that admits Animal members admits Dog members without checking further. implements works the same way for interfaces. HAS-A is different: it says a Car carries an Engine in its trunk, but that does not make a Car usable as an Engine.

Connections

Within CSCD 210/211: Every implements in the comparator material established an IS-A relationship. This leaf makes that relationship explicit and names it. The full mechanics of extends are covered later; this covers only the structural label.

Looking back: CSCD 210 introduced extends and implements. This leaf applies those keywords to the IS-A classification.

Looking ahead: Favor Composition over Inheritance explains when IS-A is the wrong design choice and HAS-A should be used instead. Association: Uses-A and Aggregation: Has-A, Can Outlive go deeper into the spectrum between the two.

Go Deeper (optional)

None of what follows is needed to write correct IS-A and HAS-A classifications. It is here for the reader who wants to see where these ideas connect to larger patterns in software design and theory.

Professional codebases. IS-A and HAS-A are the two most fundamental object-design relationships. The ability to distinguish them on sight is a prerequisite for any design discussion, code review, or inheritance decision in a professional Java codebase. When a senior engineer says “prefer composition over inheritance,” they mean: reach for HAS-A by default and use IS-A only when substitutability is the explicit goal.

Effective Java, Item 18. Joshua Bloch’s argument (in Effective Java, third edition) is that IS-A through extends should be used only when the subclass genuinely passes every test the superclass promises to pass. When in doubt, encapsulate the other class as a field (HAS-A) rather than extending it. The next concept in this tree develops exactly that argument.

The Comparator as a function object and a design pattern. A TeamComparator implements Comparator<Player> is not only an IS-A relationship: it is also a first instance of the Strategy pattern from Gamma et al. (Design Patterns, 1994), where an algorithm is encapsulated in its own object so it can be swapped at runtime. That pattern is the simplest form of a first-class function in a language that did not originally have lambdas; Java 8 lambdas and method references are the modern shorthand for the same idea.

Type theory. The Liskov substitution principle is formalized in type theory as the subtype relation, written S <: T. What Java’s type system enforces is syntactic subtyping: if S extends T, the compiler permits S wherever T is expected. Full behavioral subtyping (the original Liskov and Wing 1994 criterion) adds the requirement that preconditions cannot be strengthened and postconditions cannot be weakened in the subtype, which Java does not verify at compile time. That gap is why the principle is stated as a design rule rather than a compiler guarantee.

Practice

Level 1

Classify each relationship as IS-A or HAS-A and name the keyword or element that establishes it:

(a) class Sandwich implements Comparable<Sandwich> { ... }
(b) class Sandwich { private String name; ... }
(c) class GuestEmployee extends Employee { ... }
(d) class Team { private Player[] roster; ... }

Level 2

In F19 Lab 1, GamesPlayedComparator sorts Player objects. Identify: (a) the IS-A relationship this class declares, (b) the HAS-A relationships Player has, and (c) whether GamesPlayedComparator HAS-A Player.

Level 3

A student says: “Employee HAS-A compareTo method, so it IS-A employee ordering.” Refute this in two sentences, using the keyword rule.

Check Yourself

Close the notes and answer each one from memory, then reveal it. Pulling an idea back from memory is one of the strongest ways to make it stick.