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

Target Institution: Harvard University (SEAS Acceleration Track into CS 51)
Goal: Master Score 5 Rigor & Architectural Design Strategy

---

1. Introduction & AP Exam Weight

In the AP Computer Science A curriculum, Unit 9: Inheritance accounts for 10–15% of the Multiple-Choice section and serves as a primary foundation for the Free-Response Questions (specifically FRQ 1 and FRQ 3/4, which evaluate Object-Oriented Design and Array/ArrayList manipulations of polymorphic objects).

However, achieving a top score requires moving beyond simple syntax memorization. You must develop a precise execution model of the Java Virtual Machine (JVM). Dynamic Method Dispatch, reference type mechanics, polymorphism, and class hierarchies are not merely AP topics—they represent the fundamental building blocks of software architecture.

Placement & Strategic Context: Harvard SEAS

At Harvard University, demonstrating mastery of these concepts on the AP Computer Science A exam (achieving a Score of 5) provides an exemption from introductory programming requirements. This path allows direct placement into CS 51: Abstraction and Design in Computation. CS 51 transitions students from object-oriented subtyping in Java to functional programming paradigms, abstract data types, structural subtyping, and module systems in OCaml.

To prove readiness for CS 51, your code must demonstrate clear abstraction boundaries, proper subtyping logic, and zero runtime reference errors.

---

2. Deep Concept Breakdown

A. The Formal Subtyping and Type Systems Rules

Let $T_{\text{compile}}$ denote the Declared (Compile-Time) Type of a reference variable, and $T_{\text{runtime}}$ denote the Actual (Run-Time) Type of the object instantiated on the heap.

$$\text{Variable Declaration: } T_{\text{compile}} \ \text{obj} = \text{new } T_{\text{runtime}}();$$

In Java’s static type system, the validity of assignment and method invocation is strictly governed by the subtype relation $\le$:

1. Subtype Invariant (Liskov Substitution Principle): An assignment $x = y$ is valid at compile time if and only if: $$T_{\text{runtime}}(y) \le T_{\text{compile}}(x)$$ That is, $T_{\text{runtime}}$ must be the same class as, or a direct/indirect subclass of, $T_{\text{compile}}$.

2. Compile-Time Method Accessibility Check: For a method call $\text{obj.method}(a_1, a_2, \dots, a_n)$, the compiler searches for a valid method signature $\text{method}(A_1, A_2, \dots, A_n)$ solely within $T_{\text{compile}}$ and its superclasses: $$\text{HasMethod}(T_{\text{compile}}, \text{signature}) = \text{true}$$ If this condition is false, the compiler generates a Compile-Time Error (cannot find symbol), regardless of whether $T_{\text{runtime}}$ defines the method.

3. Run-Time Dynamic Method Dispatch Algorithm: When executing $\text{obj.method}(a_1, a_2, \dots, a_n)$ at runtime:

4. The JVM inspects the memory header of the instance on the Heap to determine $T_{\text{runtime}}$.
5. The JVM searches for the method implementation starting at $T_{\text{runtime}}$: $$\text{Dispatch}(T_{\text{runtime}}, \text{signature}) = \begin{cases} \text{Execute } M_{T_{\text{runtime}}} & \text{if } \text{Overridden}(T_{\text{runtime}}, \text{signature}) \ \text{Dispatch}(\text{Superclass}(T_{\text{runtime}}), \text{signature}) & \text{otherwise} \end{cases}$$

---

B. Class Hierarchies, Abstract Classes, and Execution Memory Layout

An Abstract Class defines an incomplete type that cannot be instantiated directly via new. It enforces an API contract across subclasses while permitting shared implementation code.

Note on the AP Java Subset: While direct authoring of abstract classes is lightly tested on the AP exam compared to concrete class extension, understanding abstract class hierarchies is critical for conceptual questions, advanced object modeling, and college placement equivalence.

       +-------------------+
       |   BaseDataFilter  |  <-- Abstract Class (Cannot be instantiated)
       +-------------------+
                 ^
                 | extends
       +-------------------+
       | HighPassFilter    |  <-- Concrete Subclass (Must implement abstract methods)
       +-------------------+

Heap and Stack Memory Topology

Consider the execution of:

BaseDataFilter filter = new HighPassFilter(0.75);
filter.process();

STACK FRAME                                 HEAP MEMORY
+------------------------+                  +-----------------------------------+
| filter                 |                  | HighPassFilter Instance           |
| (Type: BaseDataFilter) |--------------->  |-----------------------------------|
+------------------------+                  | Header: Class metadata pointer    |
                                            |   --> Points to HighPassFilter.class  |
                                            | Fields:                           |
                                            |   double threshold = 0.75         |
                                            +-----------------------------------+

---

C. Concrete Java Implementation: Mechanics of Dispatch & Constructor Chaining

Below is a complete, syntactically precise Java implementation demonstrating abstract classes, constructor chaining via super, explicit casting, and dynamic method dispatch.

/**
 * Abstract class representing a general data processing node.
 * Demonstrates state encapsulation and abstract method contracts.
 */
public abstract class DataProcessor {
    private String processorId;

    public DataProcessor(String processorId) {
        // Explicit super() to Object occurs implicitly if omitted
        this.processorId = processorId;
    }

    public String getProcessorId() {
        return processorId;
    }

    /**
     * Abstract method contract. Subclasses MUST override this method 
     * unless they are also declared as abstract.
     */
    public abstract double processData(double input);

    public void logAndProcess(double rawValue) {
        // Dynamic method dispatch executes the subclass implementation 
        // of processData at runtime.
        double result = processData(rawValue);
        System.out.println("Processor [" + processorId + "] Output: " + result);
    }
}

/**
 * Concrete Subclass 1: Implements thresholding logic.
 */
public class ThresholdFilter extends DataProcessor {
    private double cutoff;

    public ThresholdFilter(String id, double cutoff) {
        super(id); // Execution Step 1: Pass control to superclass constructor first
        this.cutoff = cutoff;
    }

    @Override
    public double processData(double input) {
        if (input < cutoff) {
            return 0.0;
        }
        return input;
    }

    // Subclass-specific method NOT declared in DataProcessor
    public void setCutoff(double newCutoff) {
        this.cutoff = newCutoff;
    }
}

---

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

Crucial Pitfalls That Separate Score 4 from Score 5

Pitfall 1: Attempting to Invoke Subclass-Specific Methods via Supertype References

DataProcessor proc = new ThresholdFilter("TF-101", 5.0);
proc.setCutoff(10.0); // COMPILE-TIME ERROR!

• Why it fails: $T_{\text{compile}}$ is DataProcessor. The compiler checks if setCutoff(double) exists in DataProcessor. Because it does not, compilation fails—even though $T_{\text{runtime}}$ (ThresholdFilter) possesses the method.
• The Fix: Explicit downcasting with compile-time type verification: java if (proc instanceof ThresholdFilter) { ((ThresholdFilter) proc).setCutoff(10.0); }

Pitfall 2: Implicit Constructor Call Failures (super())

If a superclass defines a custom constructor with parameters and does not explicitly provide a no-argument constructor, any subclass constructor that omits super(...) will trigger a compilation error.

public class Base {
    public Base(int x) { ... }
}

public class Sub extends Base {
    public Sub() {
        // Java implicitly inserts super(); 
        // COMPILE ERROR: Base() constructor is undefined!
    }
}

Pitfall 3: Overriding vs. Overloading Signature Misunderstandings

• Overriding: Same method name, exact same parameter signature, same or covariant return type. Triggers Dynamic Method Dispatch.
• Overloading: Same method name, different parameter signature. Resolved entirely at Compile-Time.

public class Parent {
    public void compute(double x) { System.out.println("Parent"); }
}

public class Child extends Parent {
    // Overloads, DOES NOT override!
    public void compute(int x) { System.out.println("Child"); } 
}

Parent obj = new Child();
obj.compute(5.0); // Prints "Parent" because compute(double) is invoked!

---

Score 4 vs. Score 5 AP Rubric Comparison

Evaluation Category	Score 4 Performance	Score 5 Rigorous Performance
Polymorphic Arrays/ArrayLists	Loops through collections using explicit downcasts without checking type bounds, risking runtime exceptions.	Iterates cleanly through base-type references, relying entirely on dynamic method dispatch without unsafe downcasting.
Encapsulation in Subclasses	Directly accesses superclass fields or attempts to modify private superclass variables directly.	Uses explicit getter/setter mechanisms or calls super(...) constructors to preserve strict abstraction boundaries.
Constructor Mechanics	Forgets super(...) calls when superclass lacks default constructors, breaking compilation chains.	Perfectly constructs object inheritance chains, placing super(...) strictly as the first line in subclass constructors.
Type Checking Diagnostics	Confuses compile-time scope checks with runtime exception behavior in MCQ tracing problems.	Instantly differentiates between static type checking failures (cannot find symbol) and dynamic runtime failures (ClassCastException).

---

4. Harvard University Placement Pathway

Transitioning from Java OOP (AP CS A) to CS 51 (Harvard SEAS)

At Harvard SEAS, passing the AP CS A exam with a 5 allows you to fulfill introductory programming requirements and enter CS 51: Abstraction and Design in Computation. CS 51 introduces key functional design patterns that directly build on Java's dynamic dispatch model:

[ AP CS A: Java Nominal Subtyping ] 
   └── Subclassing (`extends`)
   └── Dynamic Method Dispatch (Runtime Method Lookup Table)
        │
        ▼  Transforming Object Design into Functional Paradigms
[ Harvard CS 51: Abstraction & Design ]
   └── Structural Subtyping & Parametric Polymorphism
   └── OCaml Abstract Data Types (ADTs) & Pattern Matching
   └── First-Class Functions as Dispatch Mechanisms

Key Conceptual Connections:

1. Nominal Subtyping vs. Parametric Polymorphism: In Java (AP CS A), polymorphism is nominal (based on explicit class declarations: class Sub extends Super). In CS 51, you will evaluate parametric polymorphism and structural subtyping, where types are matched based on signatures and structural compatibility rather than explicit inheritance trees.

2. Dynamic Dispatch vs. Pattern Matching: Dynamic method dispatch in Java delegates runtime decision-making to the instance's type: java // Java Dynamic Dispatch shape.draw(); // Action depends on whether shape is Circle, Square, etc. In CS 51, you will implement this same abstraction using algebraic data types and structural pattern matching in OCaml: ```ocaml ( OCaml Functional Equivalent in CS 51 ) type shape = Circle of float | Square of float

let draw s = match s with | Circle r -> draw_circle r | Square w -> draw_square w ```

1. Abstraction Barriers: Understanding class encapsulation (private/protected access) prepares you for the formal abstraction barriers enforced by module interfaces (sig ... end) in CS 51.

---

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

Free-Response Question Scenario

Design an analytics tracking system for an automated trading engine.

1. Create an abstract base class TradingStrategy containing:
2. A private String strategyId field.
3. A constructor initializing strategyId.
4. A getter method getStrategyId().

5. An abstract method evaluateSignal(double marketPrice) returning a String ("BUY", "SELL", or "HOLD").

6. Create a concrete subclass MomentumStrategy extending TradingStrategy:

7. A private double targetPrice field.
8. A constructor taking (String strategyId, double targetPrice).

9. An implementation of evaluateSignal:

   • Returns "BUY" if marketPrice < targetPrice * 0.95
   • Returns "SELL" if marketPrice > targetPrice * 1.05
   • Returns "HOLD" otherwise.

10. Complete the client class method PortfolioManager.executeAll:

11. Iterates through an ArrayList<TradingStrategy>, evaluates signals against a given currentPrice, and returns an array of strings containing execution records formatted as: "[strategyId] -> [SIGNAL]".

---

Canonical Solution

import java.util.ArrayList;

// Part 1: Abstract Base Class
public abstract class TradingStrategy {
    private String strategyId;

    public TradingStrategy(String strategyId) {
        this.strategyId = strategyId;
    }

    public String getStrategyId() {
        return strategyId;
    }

    public abstract String evaluateSignal(double marketPrice);
}

// Part 2: Concrete Subclass
public class MomentumStrategy extends TradingStrategy {
    private double targetPrice;

    public MomentumStrategy(String strategyId, double targetPrice) {
        super(strategyId); // Required call to superclass constructor
        this.targetPrice = targetPrice;
    }

    @Override
    public String evaluateSignal(double marketPrice) {
        if (marketPrice < targetPrice * 0.95) {
            return "BUY";
        } else if (marketPrice > targetPrice * 1.05) {
            return "SELL";
        } else {
            return "HOLD";
        }
    }
}

// Part 3: Client Processing Class
public class PortfolioManager {

    /**
     * Evaluates all strategies polymorphically using dynamic method dispatch.
     */
    public static String[] executeAll(ArrayList<TradingStrategy> strategies, double currentPrice) {
        String[] results = new String[strategies.size()];

        for (int i = 0; i < strategies.size(); i++) {
            TradingStrategy strat = strategies.get(i);

            // Dynamic Method Dispatch: Dispatches to actual runtime subclass implementation
            String signal = strat.evaluateSignal(currentPrice); 

            results[i] = strat.getStrategyId() + " -> " + signal;
        }

        return results;
    }
}

---

Scoring Rubric & Grading Checklist

Points	Scoring Criterion	Implementation Detail Inspected
1 pt	Header & Extension	public class MomentumStrategy extends TradingStrategy correctly formed.
1 pt	Constructor Chaining	Subclass constructor explicitly calls super(strategyId) as its first execution line.
1 pt	Private Field Encapsulation	targetPrice declared as private double. No superclass private variables accessed directly.
1 pt	Abstract Method Implementation	@Override public String evaluateSignal(double marketPrice) implemented with exact signature matching.
1 pt	Correct Mathematical Logic	Bounds checked using correct thresholds (* 0.95 and * 1.05) returning correct strings.
1 pt	Array Initialization	results initialized to correct length strategies.size().
1 pt	Polymorphic Dispatch Loop	Loops through ArrayList using get(i) or enhanced for loop, calling evaluateSignal on abstract base reference type.
1 pt	String Formatting & Return	Correctly concatenates getStrategyId() + " -> " + signal into string output array.

---

6. Execution Model Summary Strategy for AP CSA Success

To achieve a 5 on the AP Exam and prepare for acceleration at top universities:

$$\text{Declared Type } (T_{\text{compile}}) \implies \text{Validates Method Existence at Compile Time}$$

$$\text{Actual Instance Type } (T_{\text{runtime}}) \implies \text{Determines Actual Executed Method Implementation at Run Time}$$

1. When evaluating static compilation: Look only at $T_{\text{compile}}$. If the method isn't declared there or in its superclasses, trigger a compile error.
2. When evaluating runtime execution: Look only at $T_{\text{runtime}}$. Follow the class hierarchy upward until you find the dynamic override, then execute that method implementation.