0.2.1.1. Member Visibility and the Protected Access Modifier¶

When designing inheritance hierarchies, how should instance variables and helper methods be scoped? In Chapter 5, you learned about private (accessible only within the declaring class) and public (accessible by any class). Java provides an intermediate access modifier designed specifically for class hierarchies: protected.

Members declared with the protected keyword are accessible to:

1. The class that defines them.

2. Any subclass that extends that class (even if the subclass resides in a different package).

3. Any class residing within the same package.

In the ChessPiece example above, row and col were marked protected. This permits subclasses such as Bishop or Knight to directly inspect and update coordinate coordinates during custom moves, while preventing arbitrary outside classes (such as a user-interface widget) from bypassing game rules.

0.2.2.1. Understanding Composition vs. Aggregation¶

Within HAS-A relationships, we distinguish between two variations based on object ownership and lifecycles:

• Composition (Part-Whole Ownership): In composition, the container object owns its component parts. The component objects are typically instantiated directly inside the container’s constructor using new. The parts usually do not exist independently outside the container, and when the container object is discarded, its internal parts are destroyed with it. For example, a Car is composed of an Engine and four Wheel instances.

• Aggregation (Shared Association): In aggregation, an object holds a reference to another object that has an independent existence. The associated object is typically passed into the container via a constructor parameter or setter method. For example, a Course aggregates Student objects: students exist before enrolling in the course, remain in existence if the course is dropped, and can simultaneously participate in multiple courses.

0.2.2.2. The Liskov Substitution Principle and Design Pitfalls¶

A common beginner mistake is using inheritance simply to share or reuse code when no genuine IS-A relationship exists. For example, imagine designing a tabletop roleplaying game with a Shield class that encapsulates armor defense and damage blocking:

public class Shield
{
    private int defenseRating;

    public Shield(int defenseRating)
    {
        this.defenseRating = Math.max(0, defenseRating);
    }

    public int block(int incomingDamage)
    {
        return Math.max(0, incomingDamage - defenseRating);
    }

    public int getDefenseRating()
    {
        return defenseRating;
    }
}

Now, suppose you want to create a Knight class that can block incoming damage. Because Shield already provides a working block() method, you might be tempted to write:

// Flawed design: Violates IS-A relationship!
public class Knight extends Shield
{
    private String name;

    public Knight(String name, int defenseRating)
    {
        super(defenseRating);
        this.name = name;
    }

    // ...
}

While this code compiles, it introduces severe architectural and conceptual flaws. Because Knight extends Shield, Java treats every Knight as an actual Shield! Any client code expecting a Shield—such as blacksmith.polish(Shield s) or warrior.equip(Shield s)—would legally accept a Knight object. A warrior could literally equip a knight as a piece of armor!

The formal design rule governing valid inheritance is known as the Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types without altering any of the desirable properties or guarantees of the program. If a proposed subclass cannot legitimately substitute for the superclass in every valid context, inheritance is inappropriate. A knight is not a shield; rather, a knight has a shield.

Instead, favor Composition:

// Clean design: Composition with Delegation
public class Knight
{
    private String name;
    private Shield shield;

    public Knight(String name, Shield shield)
    {
        this.name = name;
        this.shield = shield;
    }

    public int defend(int incomingDamage)
    {
        // Delegate defense calculation to the encapsulated Shield
        return shield.block(incomingDamage);
    }

    public Shield getShield()
    {
        return shield;
    }
}

By encapsulating Shield as a private instance variable, Knight delegates defensive calculations to its companion shield while maintaining a clean, realistic conceptual model.

0.2.3.1. The Four Rules of Method Overriding¶

To successfully override an inherited method, Java enforces four strict rules:

1. Exact Method Name: The method name must match the superclass method character-for-character.

2. Exact Parameter List: The number, order, and data types of all parameters must match exactly.

3. Compatible Return Type: The return type must match the superclass return type (or be a compatible subtype, known as a covariant return).

4. Access Visibility: The access modifier cannot be more restrictive than the parent method. If a superclass method is public, the overriding method in the subclass must also be public. It cannot be downgraded to protected or private.

0.2.3.2. Overriding vs. Method Overloading¶

It is essential to distinguish between overriding and overloading, which are frequently confused:

0.2.3.3. The @Override Annotation¶

Whenever you intend to override a method, you should always place the @Override annotation directly above the method header:

@Override
public void takeDamage(int amount)
{
    // specialized implementation
}

While Java does not require this annotation for the program to compile, omitting it is dangerous. The @Override annotation instructs the compiler to verify that a matching method actually exists in an ancestor class.

If you make a subtle typo—such as misspelling a method name or slightly modifying a parameter type—the compiler will immediately alert you:

public class ArmoredCombatant extends Combatant
{
    // BUG: Misspelled method name!
    // Without @Override, the compiler silently creates a brand-new method.
    // With @Override, the compiler halts with:
    // "method does not override or implement a method from a supertype"
    @Override
    public void takeDamge(int amount)
    {
        super.takeDamage(amount / 2);
    }
}

Without @Override, Java would treat takeDamge as a completely new, separate method. At runtime, whenever the game engine called takeDamage, your armor code would be ignored, and the default parent behavior would execute! The @Override annotation eliminates this entire category of silent bugs.

0.2.3.4. Implementing Overrides: A Combatant Hierarchy¶

Let’s examine a concrete class hierarchy modeling game combatants. First, consider a base Combatant class:

public class Combatant
{
    private String name;
    private int health;

    public Combatant(String name, int health)
    {
        this.name = name;
        this.health = Math.max(0, health);
    }

    // Secondary constructor defaulting health to 100 using same-class chaining
    public Combatant(String name)
    {
        this(name, 100);
    }

    public String getName()
    {
        return name;
    }

    public int getHealth()
    {
        return health;
    }

    public boolean isDefeated()
    {
        return health <= 0;
    }

    public void takeDamage(int amount)
    {
        if (amount > 0)
        {
            this.health = Math.max(0, this.health - amount);
        }
    }

    @Override
    public String toString()
    {
        return name + " (Health: " + health + ")";
    }
}

Notice that Combatant overrides toString(), replacing the default Object@hashcode string with a descriptive summary of its name and health.

Now, let’s create a specialized subclass, ArmoredCombatant. An armored combatant possesses an integer armorRating that mitigates incoming damage before it affects health. It overrides takeDamage to incorporate this protection:

public class ArmoredCombatant extends Combatant
{
    private int armorRating;

    public ArmoredCombatant(String name, int health, int armorRating)
    {
        super(name, health);
        this.armorRating = Math.max(0, armorRating);
    }

    // Secondary constructor defaulting health to 100 using same-class chaining
    public ArmoredCombatant(String name, int armorRating)
    {
        this(name, 100, armorRating);
    }

    public int getArmorRating()
    {
        return armorRating;
    }

    @Override
    public void takeDamage(int amount)
    {
        // Armor absorbs damage point-for-point
        int effectiveDamage = Math.max(0, amount - armorRating);

        // Forward the reduced damage to the parent logic
        super.takeDamage(effectiveDamage);
    }
}

Notice how ArmoredCombatant calls super.takeDamage(effectiveDamage). The super keyword allows a subclass to invoke the parent class’s version of an overridden method. This preserves the parent’s encapsulation and logic (such as preventing health from dropping below zero) while adding custom specialization.

0.2.3.5. Constructor Chaining: Initializing State with super() and this()¶

When designing classes, constructors play a special role: constructors are not inherited. A subclass cannot simply use a superclass constructor as its own because constructors are responsible for initializing the exact fields declared in their own class.

To ensure every object is properly initialized from the top of the hierarchy downward, Java provides two forms of constructor chaining:

1. Superclass Constructor Chaining (super(...)): Before a subclass constructor can initialize any of its own fields, the superclass portion of the object must be initialized. In ArmoredCombatant:

   public ArmoredCombatant(String name, int health, int armorRating)
   {
       super(name, health); // 1. Must be the FIRST statement
       this.armorRating = Math.max(0, armorRating); // 2. Initialize subclass fields
   }
   

   • The call to super(...) invokes the matching constructor in the direct superclass (Combatant).

   • Rule: If present, super(...) must be the very first statement inside the subclass constructor body.

   • Default Behavior: If you do not explicitly write super(...), the Java compiler automatically inserts a parameterless super(); call as the first line. If the superclass does not have a no-argument constructor, a compile-time error occurs.

2. Same-Class Constructor Chaining (this(...)): Classes frequently provide multiple overloaded constructors to offer convenient default parameter values. Rather than copying and pasting field assignment code across every constructor, a constructor can delegate to another constructor within the same class using this(...):

   // Primary constructor
   public Combatant(String name, int health)
   {
       this.name = name;
       this.health = Math.max(0, health);
   }
   
   // Secondary constructor: delegates to the primary constructor with default health
   public Combatant(String name)
   {
       this(name, 100); // Calls the 2-parameter constructor above!
   }
   

   • Just like super(...), a this(...) call must be the very first statement in the constructor body.

   • Mutual Exclusivity: A constructor can call this(...) OR super(...), but never both in the same constructor. When this(...) is called, the constructor delegates to a peer constructor, which will in turn invoke super(...) to initialize the superclass. This ensures the superclass initialization happens exactly once.

0.2.3.6. Testing Overridden Methods with AssertJ¶

In CS 1114, automated unit tests written in JUnit 5 and AssertJ verify that subclasses correctly specialize parent behaviors:

import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.*;

class CombatantTest
{
    @Test
    void testStandardCombatantTakesFullDamage()
    {
        Combatant scout = new Combatant("Scout", 100);
        scout.takeDamage(30);

        assertThat(scout.getHealth()).isEqualTo(70);
        assertThat(scout.isDefeated()).isFalse();
    }

    @Test
    void testArmoredCombatantReducesDamageByArmorRating()
    {
        // Armor rating of 10 should mitigate 10 points of incoming damage
        ArmoredCombatant knight = new ArmoredCombatant("Knight", 100, 10);
        knight.takeDamage(30);

        // 30 incoming damage - 10 armor = 20 effective damage
        assertThat(knight.getHealth()).isEqualTo(80);
    }

    @Test
    void testArmorFullyAbsorbsWeakAttack()
    {
        ArmoredCombatant knight = new ArmoredCombatant("Knight", 100, 15);
        knight.takeDamage(10);

        // Attack was weaker than armor; zero damage sustained
        assertThat(knight.getHealth()).isEqualTo(100);
    }
}

0.2.4.1. Static Type vs. Dynamic Type¶

To understand how polymorphism functions behind the scenes in Java, we must separate two distinct aspects of every reference variable:

1. Static Type (Compile-Time Type): The type declared in the source code when the variable is introduced. The Java compiler consults the static type to verify that any method you attempt to call is legally available.

2. Dynamic Type (Run-Time Type): The actual class of the concrete object created in computer memory via the new operator.

Consider this declaration:

Combatant soldier = new ArmoredCombatant("Paladin", 120, 15);

• The static type of soldier is Combatant.

• The dynamic type of the object referenced by soldier is ArmoredCombatant.

0.2.4.2. How Dynamic Method Dispatch Works¶

When the program executes a method invocation such as soldier.takeDamage(40);, how does the Java Virtual Machine decide which version of takeDamage to run?

1. At Compile Time: The compiler inspects the static type of soldier (Combatant). It confirms that the Combatant class declares a method named takeDamage(int). If no such method exists in Combatant, compilation fails.

2. At Run Time: When execution reaches this statement, the JVM ignores the static type of the variable. Instead, it examines the dynamic type of the actual receiver object stored in heap memory.

3. The JVM locates the method implementation starting at the object’s dynamic class (ArmoredCombatant). Since ArmoredCombatant provides an overridden version of takeDamage, that specialized version executes!

This runtime selection of the method implementation based on the dynamic type of the receiver object is known as dynamic method dispatch (or late binding).

[Stack Memory]                         [Heap Memory]
+----------------------+               +--------------------------------------+
| soldier (Ref)        | ------------> | Object of class ArmoredCombatant     |
| Static: Combatant    |               | Dynamic: ArmoredCombatant            |
+----------------------+               | Fields: name="Paladin", health=120,  |
                                       |         armorRating=15               |
                                       +--------------------------------------+
                                                          |
                                      Dynamic Method      v
                                      Dispatch to: ArmoredCombatant.takeDamage()

0.2.4.3. Tracing Multi-Tier Hierarchies¶

Dynamic dispatch applies seamlessly across deep, multi-tier class hierarchies. Suppose we extend our combatant system with a third tier:

Combatant
   ▲
   │ extends
ArmoredCombatant
   ▲
   │ extends
FortifiedJuggernaut

If FortifiedJuggernaut overrides takeDamage, calling takeDamage on a FortifiedJuggernaut instance executes that code. If it does not override takeDamage, the JVM steps up the hierarchy to ArmoredCombatant. If ArmoredCombatant implements it, that version runs; otherwise, the JVM continues upward to Combatant. The JVM always executes the implementation closest to the dynamic type in the inheritance chain.

0.2.5.1. The “Type as a Lens” Metaphor¶

A helpful way to understand reference variables is to think of the variable’s type as a lens or a window through which you observe an object.

Combatant hero = new ArmoredCombatant("Aegis", 100, 12);

Even though the underlying object in memory is an ArmoredCombatant, our variable hero looks at that object through a Combatant lens. This leads to two critical rules:

1. What You Can Call (Static Check): The lens restricts what you are allowed to ask the object to do. The compiler only permits you to call methods defined in the static type Combatant.

2. How It Behaves (Dynamic Dispatch): When you invoke an accessible method, the object responds using its dynamic type’s logic.

Consider what happens if we attempt to call a method that exists only in the subclass:

Combatant hero = new ArmoredCombatant("Aegis", 100, 12);

// Valid: takeDamage() is declared in Combatant; executes ArmoredCombatant version!
hero.takeDamage(25);

// COMPILE ERROR: cannot find symbol method getArmorRating()
int armor = hero.getArmorRating();

Why does hero.getArmorRating() fail to compile? Because the compiler looks only at the static type Combatant, and Combatant does not have a getArmorRating() method. The compiler does not know—and cannot assume—that hero will point to an ArmoredCombatant at runtime.

0.2.5.2. Polymorphic Aggregation: Modeling a Squad¶

The true practical power of polymorphic references emerges when composing complex objects from simpler ones. In a simulation or game, you often group related entities together into larger units. In Chapter 8, we will learn how to store arbitrary numbers of objects in dynamic collections like lists. Even with the tools we have right now, we can combine polymorphic objects using object aggregation with named fields.

Consider a Squad composed of two combatants assigned to different tactical positions: a front line combatant and a back line combatant:

public class Squad
{
    private Combatant frontLine;
    private Combatant backLine;

    public Squad(Combatant frontLine, Combatant backLine)
    {
        this.frontLine = frontLine;
        this.backLine = backLine;
    }

    public Combatant getFrontLine()
    {
        return frontLine;
    }

    public Combatant getBackLine()
    {
        return backLine;
    }

    /**
     * Applies area-of-effect damage to both squad positions.
     * @param amount the raw damage incoming to each squad member
     */
    public void takeAreaDamage(int amount)
    {
        frontLine.takeDamage(amount);
        backLine.takeDamage(amount);
    }
}

Notice how Squad uses generalized Combatant references for both of its fields. This makes the squad heterogeneous: we can assemble a squad containing any combination of regular Combatant and specialized ArmoredCombatant instances:

Combatant archer = new Combatant("Archer", 70);
Combatant knight = new ArmoredCombatant("Vanguard Knight", 120, 15);

Squad squad = new Squad(knight, archer);

// Apply area-of-effect damage to the entire squad
squad.takeAreaDamage(25);

When squad.takeAreaDamage(25) executes:

• When frontLine.takeDamage(25) is called, dynamic dispatch invokes ArmoredCombatant’s overridden version because frontLine refers to a knight! Armor absorbs 15, reducing health by only 10.

• When backLine.takeDamage(25) is called, standard Combatant damage logic executes because backLine refers to an archer. Health drops by the full 25.

• The Squad class does not need any if-else checks to inspect what kind of combatant is in each position.

This is the essence of object-oriented design: client code sends messages to generalized references, and individual objects specialize their responses autonomously.

0.2.5.3. AssertJ Verification of Polymorphic Assignment¶

You can write unit tests that verify both the static behavior and dynamic identity of polymorphically assigned objects:

import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.*;

class PolymorphicAssignmentTest
{
    @Test
    void testPolymorphicDispatchInSquad()
    {
        Combatant scout = new Combatant("Scout", 100);
        Combatant knight = new ArmoredCombatant("Knight", 100, 10);

        Squad team = new Squad(knight, scout);

        // Hit both team positions with 20 area-of-effect damage
        team.takeAreaDamage(20);

        // Knight in front line absorbed 10 via armor: 100 - (20 - 10) = 90
        assertThat(knight.getHealth()).isEqualTo(90);

        // Scout in back line took full 20 damage: 100 - 20 = 80
        assertThat(scout.getHealth()).isEqualTo(80);

        // AssertJ can inspect the dynamic type of reference variables
        assertThat(scout).isExactlyInstanceOf(Combatant.class);
        assertThat(knight).isInstanceOf(Combatant.class);
        assertThat(knight).isExactlyInstanceOf(ArmoredCombatant.class);
    }
}

0.2.6.1. Single Inheritance vs. Multiple Interfaces¶

A fundamental design decision in Java is that a class can extend at most one superclass. This is known as single inheritance. Multiple class inheritance (which is allowed in languages like C++) can create tricky structural ambiguities, such as the famous “Diamond Problem,” where two parent classes define conflicting versions of the same method or state.

However, a class in Java may implement as many interfaces as needed.

Suppose our game environment also needs entities capable of producing audio effects. We can define a second interface, Audible:

public interface Audible
{
    /**
     * Plays the audio effect associated with this entity.
     */
    void playSound();
}

Now, a class can inherit core state and implementation from a superclass while simultaneously fulfilling both independent interface contracts:

public class ArmoredCombatant extends Combatant
    implements Drawable, Audible
{
    public ArmoredCombatant(String name, int health, int armorRating)
    {
        super(name, health, armorRating);
    }

    @Override
    public void draw()
    {
        // Render armor and weapon graphics
    }

    @Override
    public void playSound()
    {
        // Play sound effect of clanking metal armor
    }
}

Here, ArmoredCombatant inherits state and default behaviors from Combatant, while simultaneously fulfilling the behavioral contracts of both Drawable and Audible.

0.2.7.1. Implementing Concrete Dice Classes¶

Now we can implement specialized classes conforming to Rollable:

import student.util.Random;

public class StandardDie implements Rollable
{
    private int sides;
    private Random generator;

    public StandardDie(int sides)
    {
        this.sides = Math.max(1, sides);
        this.generator = Random.generator();
    }

    // Secondary constructor defaulting to standard 6-sided die via same-class chaining
    public StandardDie()
    {
        this(6);
    }

    @Override
    public int getSides()
    {
        return sides;
    }

    @Override
    public int roll()
    {
        return generator.nextInt(sides) + 1;
    }
}

Next, consider an AdvantageDie, a common mechanic in tabletop gaming where a player rolls twice and keeps the superior result:

public class AdvantageDie implements Rollable
{
    private Rollable baseDie;

    public AdvantageDie(Rollable baseDie)
    {
        this.baseDie = baseDie;
    }

    @Override
    public int getSides()
    {
        return baseDie.getSides();
    }

    @Override
    public int roll()
    {
        int roll1 = baseDie.roll();
        int roll2 = baseDie.roll();
        return Math.max(roll1, roll2);
    }
}

Notice how AdvantageDie uses Composition and Delegation! It does not need to know how baseDie generates numbers; it simply delegates the roll operation twice to its encapsulated Rollable instance and computes the maximum.

0.2.7.2. Polymorphic Dice Rolling in Game Engines¶

Now, imagine constructing a DicePair used in tabletop games to roll two dice together:

public class DicePair
{
    private Rollable firstDie;
    private Rollable secondDie;

    public DicePair(Rollable firstDie, Rollable secondDie)
    {
        this.firstDie = firstDie;
        this.secondDie = secondDie;
    }

    /**
     * Rolls both dice and sums their total value.
     * @return aggregate roll total.
     */
    public int rollTotal()
    {
        return firstDie.roll() + secondDie.roll();
    }
}

Because DicePair depends strictly on the Rollable interface rather than concrete classes, players can combine any pairing of StandardDie and AdvantageDie. The rolling logic never changes, demonstrating the open/closed principle: software should be open for extension, but closed for modification.

0.2.7.3. Testing Game Entities with AssertJ¶

To verify our game framework in automated unit tests, we can supply predictable substitutions (stubs) that implement Rollable:

// A deterministic die stub for automated testing
class DeterministicDie implements Rollable
{
    private int fixedValue;

    public DeterministicDie(int fixedValue)
    {
        this.fixedValue = fixedValue;
    }

    @Override
    public int getSides()
    {
        return 6;
    }

    @Override
    public int roll()
    {
        return fixedValue;
    }
}

// A test stub that alternates between two values
class AlternatingDie implements Rollable
{
    private int count = 0;

    @Override
    public int getSides()
    {
        return 6;
    }

    @Override
    public int roll()
    {
        count++;
        return (count % 2 == 1) ? 2 : 5;
    }
}

import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.*;

class DiceFrameworkTest
{
    @Test
    void testStandardDieBounds()
    {
        StandardDie d6 = new StandardDie(6);
        int rolls = 0;
        while (rolls < 50)
        {
            int value = d6.roll();
            assertThat(value).isBetween(1, 6);
            rolls++;
        }
    }

    @Test
    void testDicePairPolymorphicSum()
    {
        Rollable die1 = new DeterministicDie(4);
        Rollable die2 = new DeterministicDie(5);

        DicePair pair = new DicePair(die1, die2);
        assertThat(pair.rollTotal()).isEqualTo(9);
    }

    @Test
    void testAdvantageDieSelectsMaxRoll()
    {
        Rollable alternatingDie = new AlternatingDie();
        AdvantageDie advantage = new AdvantageDie(alternatingDie);
        assertThat(advantage.roll()).isEqualTo(5);
    }
}