Replacing a computation entirely.
Sometimes the subclass's logic is fundamentally different — and the right move is to override without calling super.
Not every override needs to call super. When the subclass's computation is independent of (or contradicts) the parent's, the override replaces the logic entirely.
The canonical example: a Shape class with a placeholder area() returning 0; each subclass (Circle, Square, Triangle) provides its own formula with no reference to the parent.
On the AP exam, this is the pattern in shape FRQs, animal-sound FRQs, and any inheritance hierarchy where each subclass has its own formula.
Provide a new implementation; don't call super.
The subclass formula is the whole answer.
Example: Shape hierarchy
public class Shape {
public double area() { return 0; }
}
public class Circle extends Shape {
private double radius;
public Circle(double r) { radius = r; }
@Override
public double area() {
return Math.PI * radius * radius;
}
}
public class Square extends Shape {
private double side;
public Square(double s) { side = s; }
@Override
public double area() {
return side * side;
}
}Neither Circle nor Square calls super.area(). The parent's area() returning 0 is a placeholder that each subclass replaces.
When NOT to call super
- The parent's implementation is a placeholder (returns 0, null, "").
- The subclass's logic doesn't logically extend the parent's.
- The parent's method has side effects you want to skip.
When TO call super
- The subclass's logic builds on the parent's result.
- The parent does useful setup or default work.
- The rubric says "in addition to".
Replacement-override vocabulary.
Used in computed-method overrides.
- Replacement override — override that doesn't call super.
- Placeholder method — parent's stub returning a default.
- Computed method — method that computes a value from fields.
- Formula — the subclass-specific calculation.
- Hierarchy — chain of inheritance relationships.
How computed overrides are tested.
Subclass formulas dispatched polymorphically dominate.
- Match the parent's signature. Same name, parameters, return type.
- Use subclass fields. Access via direct or accessor.
- Don't call super if the formula is independent. Adding super may double-count.
- Polymorphic call. A Shape reference holding a Circle calls Circle's area.
Compute areas polymorphically.
Different formulas, same call.
Setup. Shape, Circle, Square defined above.
Shape[] shapes = { new Circle(2), new Square(3) };
for (Shape s : shapes) {
System.out.println(s.area());
}Trace.
- Circle(2): Circle.area() = π × 4 ≈ 12.57.
- Square(3): Square.area() = 9.
Even though the loop variable is type Shape, the actual object's formula runs.
Computed-override pitfalls.
Most are signature or super-call errors.
- Calling super.area() when the formula is independent. Adds a stray 0 or worse.
- Different signature. Method name, params, or return type drift breaks the override.
- Trying to access private parent fields. Use accessors.
- Returning the wrong type. Must match exactly.
Replacement vs additive override.
When to call super.
Computed Override Reference
AP Quick Reference| Situation | Call super? | Example |
|---|---|---|
| Parent is placeholder | No | Shape.area() |
| Independent formula | No | Circle.area() |
| Build on parent result | Yes | Manager.getSalary() |
| Modify parent output | Yes | Dog.toString() |
How to master computed overrides.
Decide super-or-not before writing.
- MCQ Practice — for each override, decide whether super is logically needed.
- Java Lab — build Shape/Circle/Square. Verify polymorphic dispatch.
- FRQ Practice — match the parent's signature exactly; choose super or not based on the formula.
Practice — attempt these now.
AP-style assessments aligned to this lesson. Time them.
AP CSA Unit 08 Topic 06 Overriding a Computed Method FRQ Practice
AP-style topic practice assessment