AP Computer Science A Master Guide: Inheritance, Abstract Classes & Dynamic Method Dispatch

Target Institution: UC Berkeley (EECS / CS Major Pathway)
Goal: AP Exam Score 5 | Exemption from CS 10 (4 Units) | Preparation for CS 61B (Data Structures)

---

1. Introduction & AP Exam Weight

Inheritance and Polymorphism represent the core of Object-Oriented Programming (OOP) tested on the AP Computer Science A Exam. Governed primarily by Unit 9: Inheritance (comprising 5–10% of multiple-choice questions), these concepts also dictate performance on Free-Response Question 2 (Class Design) and heavily influence FRQ 1 and FRQ 3.

                  ┌───────────────────────────────┐
                  │    AP CSA Unit 9 Weightings   │
                  └──────────────┬────────────────┘
                                 │
         ┌───────────────────────┴───────────────────────┐
         ▼                                               ▼
┌─────────────────────────┐                     ┌─────────────────────────┐
│ Multiple-Choice (5-10%) │                     │ Free-Response (Q2 & Q3) │
│ • Static vs Dynamic     │                     │ • Hierarchy Design      │
│ • Compilation Errors    │                     │ • Polymorphic Calls     │
│ • Inheritance Trees     │                     │ • `super` Constructors  │
└─────────────────────────┘                     └─────────────────────────┘

The Score 5 Difference

A Score 4 student understands basic class extension (extends) and simple method overriding. A Score 5 student possesses an absolute mental model of: 1. Compile-Time Type Checking vs. Runtime Method Execution. 2. Dynamic Method Dispatch and Virtual Method Table (VTable) lookup resolution. 3. Class design principles that extend beyond the basic AP Java subset into Abstract Classes and Interfaces—skills non-negotiable for students aiming to transition directly into UC Berkeley's rigorous lower-division CS curriculum.

---

2. Deep Concept Breakdown

2.1 The Formal Type Subtyping Rule & Mechanics

Let a reference variable $o$ be declared with type $T_{\text{static}}$ (the static/declared type) and instantiated with an object of type $T_{\text{dynamic}}$ (the dynamic/actual type).

$$\text{Syntax: } \quad T_{\text{static}} \,\, o = \text{new} \,\, T_{\text{dynamic}}();$$

For the Java compiler to accept this assignment without explicit casting, the dynamic type must be a subtype of the static type in the type hierarchy:

$$T_{\text{dynamic}} \sqsubseteq T_{\text{static}}$$

where $\sqsubseteq$ represents the reflexivity and transitivity of the inheritance relationship ($A \sqsubseteq A$, and if $A \sqsubseteq B$ and $B \sqsubseteq C$, then $A \sqsubseteq C$).

Compile-Time vs. Runtime Method Resolution Rule

Given the invocation $o.\text{method}(p_1, p_2, \dots, p_n)$:

1. Compile-Time Checking (Static Verification): The compiler inspects $T_{\text{static}}$. It verifies whether $T_{\text{static}}$ (or one of its superclasses) declares a method with signature matching $\text{method}(p_1, p_2, \dots, p_n)$.

$$\text{If } \text{method} \notin \text{Methods}(T_{\text{static}}), \quad \implies \text{\textbf{Compile-Time Error}}$$

1. Runtime Dispatching (Dynamic Method Dispatch): If compilation succeeds, the Java Virtual Machine (JVM) inspects $T_{\text{dynamic}}$ at runtime. The JVM traverses up the class hierarchy starting at $T_{\text{dynamic}}$ until it finds the first concrete implementation of $\text{method}$.

$$\text{Executed Method} = \text{Resolve}(T_{\text{dynamic}}, \text{signature})$$

Compile-Time (Static Check)               Runtime (Dynamic Dispatch)
───────────────────────────               ──────────────────────────
 Look at Declared Type: T_static           Look at Actual Instance: T_dynamic
   │                                         │
   ▼                                         ▼
 Does T_static have method()?             Start at T_dynamic and walk UP 
   ├── NO  ─► COMPILE ERROR                  class hierarchy to execute 
   └── YES ─► PASSES COMPILE                 first overriden method() found.

---

2.2 Comprehensive Java Concrete Example

The following code illustrates inheritance, method overriding, super calls, abstract classes, and polymorphic arrays.

/**
 * Abstract class representing a generic Computing Node at UC Berkeley.
 * Note: While abstract classes are non-tested enrichment on AP CSA, 
 * they are foundational to object-oriented taxonomy and CS 61B.
 */
public abstract class ComputeNode {
    private String nodeId;
    private double clockSpeedGHz;

    public ComputeNode(String nodeId, double clockSpeedGHz) {
        this.nodeId = nodeId;
        this.clockSpeedGHz = clockSpeedGHz;
    }

    public String getNodeId() {
        return nodeId;
    }

    public double getClockSpeedGHz() {
        return clockSpeedGHz;
    }

    // Abstract method: MUST be overridden by concrete subclasses
    public abstract double computeComputePower();

    // Concrete method subject to dynamic dispatch overriding
    public String getStatus() {
        return "Node " + nodeId + " running at " + clockSpeedGHz + " GHz";
    }
}

/**
 * Concrete Subclass 1: GPU Accelerator Node
 */
public class GPUNode extends ComputeNode {
    private int cudaCores;

    public GPUNode(String nodeId, double clockSpeedGHz, int cudaCores) {
        super(nodeId, clockSpeedGHz); // Mandatory constructor chaining
        this.cudaCores = cudaCores;
    }

    @Override
    public double computeComputePower() {
        // TFLOPS model formula calculation
        return getClockSpeedGHz() * cudaCores * 0.002;
    }

    @Override
    public String getStatus() {
        // Explicit call to superclass method + subclass specialization
        return super.getStatus() + " [GPU Cores: " + cudaCores + "]";
    }

    // Subclass-specific method (Not visible via ComputeNode declared types)
    public void executeCUDACernel() {
        System.out.println("Executing CUDA kernel on " + getNodeId());
    }
}

/**
 * Concrete Subclass 2: CPU Server Node
 */
public class CPUNode extends ComputeNode {
    private int coreCount;

    public CPUNode(String nodeId, double clockSpeedGHz, int coreCount) {
        super(nodeId, clockSpeedGHz);
        this.coreCount = coreCount;
    }

    @Override
    public double computeComputePower() {
        return getClockSpeedGHz() * coreCount;
    }

    // Does NOT override getStatus(); inherits ComputeNode implementation
}

/**
 * Execution Engine demonstrating Dynamic Method Dispatch
 */
public class ClusterRunner {
    public static void main(String[] args) {
        // Polymorphic Array declaration
        ComputeNode[] cluster = new ComputeNode[3];

        cluster[0] = new GPUNode("gpu-node-01", 1.5, 5120);
        cluster[1] = new CPUNode("cpu-node-01", 3.8, 64);
        cluster[2] = new GPUNode("gpu-node-02", 1.8, 10752);

        System.out.println("=== POLYMORPHIC DISPATCH EXECUTION ===");
        for (ComputeNode node : cluster) {
            // DYNAMIC DISPATCH IN ACTION:
            // 1. Compiler checks: Does ComputeNode have getStatus() and computeComputePower()? YES.
            // 2. JVM executes: Actual subclass implementations at runtime.
            System.out.println(node.getStatus());
            System.out.println("Power: " + node.computeComputePower() + " UNITS\n");
        }

        // COMPILE-TIME TYPE CHECKING TRAP:
        // cluster[0].executeCUDACernel(); // COMPILE ERROR: ComputeNode doesn't have executeCUDACernel()

        // DOWNCASTING FIX (Requires explicit type cast):
        if (cluster[0] instanceof GPUNode) {
            GPUNode directGpuRef = (GPUNode) cluster[0];
            directGpuRef.executeCUDACernel(); // Compiles and executes correctly
        }
    }
}

---

3. Common AP Exam Pitfalls & Score 5 Scoring Rubric Nuances

3.1 The "Declared Type vs. Actual Type" Pitfall

The most common trap on the AP CSA exam tests whether a student can distinguish between what the compiler checks vs. what the JVM executes.

SuperClass obj = new SubClass();
obj.subclassOnlyMethod(); // COMPILE-TIME ERROR

• Why it fails: The compiler looks strictly at SuperClass (Declared Type). If subclassOnlyMethod() is not defined in SuperClass, the code will not compile, even though the actual underlying instance (SubClass) has the method!
• AP Score 4 Mistake: Claiming this results in a "NullPointerException" or "ClassCastException" at runtime.
• AP Score 5 Precision: Spotting that this is a static compilation failure before runtime ever occurs.

---

3.2 Constructor Chaining & The super() Trap

1. Rule: If a subclass constructor does not explicitly call super(...), the compiler automatically inserts an implicit call to super() (the no-argument constructor of the parent class).
2. The Pitfall: If the superclass defines a custom constructor with arguments (e.g., public Parent(int x)), the compiler removes the default no-arg constructor. If the subclass constructor then omits super(x), the implicit super() call fails to find a matching no-arg parent constructor, causing a compilation error.

class Parent {
    public Parent(int val) { System.out.println("Parent: " + val); }
}

class Child extends Parent {
    public Child() { 
        // Implicit super(); inserted here!
        // COMPILE ERROR: Parent class lacks a default Parent() constructor!
    }
}

---

3.3 Score 4 vs. Score 5 Rubric Criteria (AP FRQ Analysis)

Criteria	Score 4 Execution	Score 5 Execution
Method Overriding	Duplicates instance variables from parent class inside the child class; breaks encapsulation.	Leverages inheritance cleanly; uses super methods to inherit state and behaviors without duplication.
Subclass Constructors	Omits super(...) call or attempts to directly access private parent instance variables (this.parentVar = val).	Correctly invokes super(arg1, arg2) as the very first line of the subclass constructor.
Polymorphic Arrays	Uses manual downcasting ((ChildClass) list[i]) excessively without checking inheritance capabilities.	Employs dynamic dispatch natively. Invokes overridden interface/superclass methods directly, allowing runtime resolution.
Variable Shadowing	Confuses variable shadowing with method overriding (Variables in Java are not polymorphic; methods are).	Recognizes that instance variables are resolved statically via the declared type, avoiding field-shadowing bugs.

---

4. UC Berkeley Placement Pathway

AP CS A (Score 5)
       │
       ▼
Exempts CS 10 (4 Units)
"The Beauty and Joy of Computing"
       │
       ▼
Accelerates Directly into:
┌────────────────────────────────────────────────────────┐
│  CS 61B: Data Structures (Java)                        │
│  • Primary Gatekeeper Course for CS/EECS               │
│  • Intensely Object-Oriented & Design-Heavy            │
└────────────────────────────────────────────────────────┘

Why Dynamic Dispatch is the Primary Skill for CS 61B

At UC Berkeley, skipping CS 10 puts high-achieving students directly into CS 61B: Data Structures (taught in Java by professors such as Josh Hug or Paul Hilfinger).

CS 61B assumes complete fluency in fundamental Java syntax from Day 1 and introduces complex software abstraction within the first three weeks:

1. Interface Inheritance & Abstract Data Types (ADTs): Project 1 in CS 61B (e.g., Deque, SLList, AList) requires students to build custom data structures extending interfaces or abstract classes.
2. The Comparable & Comparator Polymorphism Engine: Efficient sorting algorithms implemented in CS 61B rely entirely on dynamic dispatch through interface constraints: $$\text{public > void sort(T[] items)}$$
3. Software Architecture Verification: CS 61B autograders evaluate design patterns. Code that relies on long if-else type-checking blocks instead of dynamic method dispatch is penalized for architectural deficiencies.

Mastering dynamic dispatch at the AP level ensures you enter CS 61B with the object-oriented foundation required to earn an A grade, protecting your upper-division CS declaration status.

---

5. High-Yield Practice Problem & Step-by-Step Solution Checklist

Problem Statement (AP CSA FRQ Style)

A local university management system processes academic roles.

1. Write the GraduateTA class, which inherits from an existing UniversityMember class.
2. UniversityMember is defined as follows:

public class UniversityMember {
    private String name;
    private double baseStipend;

    public UniversityMember(String name, double baseStipend) {
        this.name = name;
        this.baseStipend = baseStipend;
    }

    public String getName() {
        return name;
    }

    public double getBaseStipend() {
        return baseStipend;
    }

    public double calculateMonthlyPay() {
        return baseStipend;
    }
}

1. The GraduateTA class must meet the following requirements:
2. Maintains an integer instance variable for hoursTaught.
3. Maintains a constant hourly rate bonus of $35.00 per hour taught.
4. Constructor accepts name (String), baseStipend (double), and hoursTaught (int).
5. Overrides calculateMonthlyPay() to return the baseStipend plus the total hourly earnings (hoursTaught * 35.0).
6. Overrides toString() to return: "[Name] - TA Pay: $[Monthly Pay]".

---

Complete Java Implementation

public class GraduateTA extends UniversityMember {
    // Instance variable unique to subclass
    private int hoursTaught;

    // Constant for hourly rate bonus
    public static final double HOURLY_RATE = 35.0;

    /**
     * Constructor for GraduateTA.
     * Initializes parent state using super and sets local hoursTaught.
     */
    public GraduateTA(String name, double baseStipend, int hoursTaught) {
        super(name, baseStipend); // Call to superclass constructor MUST be first
        this.hoursTaught = hoursTaught;
    }

    /**
     * Calculates total monthly pay polimorphically.
     * Uses super.calculateMonthlyPay() to obtain base stipend safely.
     */
    @Override
    public double calculateMonthlyPay() {
        return super.calculateMonthlyPay() + (hoursTaught * HOURLY_RATE);
    }

    /**
     * Formats string representation using dynamic pay calculation.
     */
    @Override
    public String toString() {
        return getName() + " - TA Pay: $" + calculateMonthlyPay();
    }
}

---

Step-by-Step Solution & Execution Analysis

Trace Analysis: Execution & Dynamic Dispatch Verification

Suppose we execute the following snippet:

UniversityMember member = new GraduateTA("Alex", 2000.0, 10);
System.out.println(member.toString());

Let's trace how the JVM evaluates this execution path:

[Step 1: Declaration & Instantiation]
  Declared Type:  UniversityMember
  Actual Instantiation: GraduateTA

[Step 2: Method Call Resolution -> member.toString()]
  1. Static Check (Compiler):
     Does UniversityMember have a toString() method?
     Yes (inherited from java.lang.Object). Compiles successfully.

  2. Dynamic Resolution (JVM at Runtime):
     Inspect Actual Instance Type: GraduateTA
     Does GraduateTA override toString()? YES. Execute GraduateTA.toString().

[Step 3: Execution inside GraduateTA.toString()]
  Calls getName()            ──► Found in UniversityMember -> returns "Alex"
  Calls calculateMonthlyPay() ──► DYNAMIC DISPATCH!
                                 Invokes GraduateTA.calculateMonthlyPay()
                                 = super.calculateMonthlyPay() + (10 * 35.0)
                                 = 2000.0 + 350.0 = 2350.0

[Step 4: Final Output String]
  Returns: "Alex - TA Pay: $2350.0"

---

Canonical AP FRQ Scoring Rubric (9-Point Breakdown)

Points	Assessment Requirement	Scoring Verification
+1	Class Header	Declares public class GraduateTA extends UniversityMember.
+1	Instance Variable	Declares private int hoursTaught.
+1	Constructor Header	Declares public GraduateTA(String name, double baseStipend, int hoursTaught).
+1	Super Constructor Call	Calls super(name, baseStipend) as the first statement in the constructor.
+1	Subclass Assignment	Correctly initializes this.hoursTaught = hoursTaught.
+1	Method Header	Declares public double calculateMonthlyPay().
+1	Pay Computation	Computes base pay + (hours * rate) without accessing private fields directly. Uses super.calculateMonthlyPay() or getBaseStipend().
+1	toString Header & Body	Correctly overrides toString() and formats output string matching specifications.
+1	Encapsulation & Syntax	All instance variables are private; public accessors used; correct Java syntax throughout.

---

6. Strategic Advice for Exam Day

1. Watch Out for Abstract Class/Interface Misconceptions on Multiple-Choice Questions:
2. Abstract classes cannot be instantiated directly (new AbstractClass() causes a compiler error).
3. Interfaces contain abstract public methods (prior to Java 8/9 default features) and public static final constants only.
4. Track the Reference Type for Method Access, Track the Object Type for Method Execution:
5. Remember the golden rule: "Declared type decides what you can call; Actual type decides what actually runs."
6. Always Check Constructor Signatures:
7. If a subclass constructor doesn't explicitly call super(...), make sure the parent class has a 0-argument constructor. If it doesn't, mark that option as a Compilation Error.