FRQ 2 – Class Design

Overview

AP CSA FRQ 2 is the Class Design question, worth 7 of the 25 points in the free-response section of the AP Computer Science A exam. You get 90 minutes for all four FRQs (the section counts for 45% of your exam score), which works out to roughly 20-22 minutes for this question. FRQ 2 gives you a scenario, written specifications, and a table of example method calls with their results, then asks you to write a complete class from scratch: the class header, private instance variables, a constructor, and at least one method, fully implemented.

This is the only FRQ where you design an entire class instead of filling in methods inside one. The scenario is always something familiar (a vending machine, a game, a reservation system) so you can focus on the code, not the setup. A second class might appear in the question too. The exam is fully digital, so you'll type your class in the testing app, and you'll have the Java Quick Reference available the whole time.

For the bigger picture on the whole exam, see the AP Computer Science A exam prep hub.

How AP CSA FRQ 2 Is Scored

FRQ 2 is worth 7 points, and the official requirements are clear: your class must include a class header, instance variables, a constructor, a method, and working implementations of that constructor and method. Based on how Class Design questions have been scored, the points typically break down like this:

Two things make this rubric feel strict. First, points are whole points only. A string that says "Order numer 1" instead of "Order number 1" can cost you the return-value point entirely, so proofread your string literals. Second, graders score what's on the page, not what you meant. If a return statement is missing from your else branch, that point is gone even if the rest is perfect.

One piece of good news: the seven points are mostly independent. A buggy method doesn't erase your class header, instance variable, and constructor points. Even if the algorithm scares you, writing a clean skeleton can bank 4-5 points.

How to Write the Class Design FRQ, Step by Step

The winning approach is systematic: read the examples table first, figure out what state the object tracks, then build the class in order from header to methods. Here's a timing plan for an approximately 22-minute budget.

Minutes 1-5: Read everything and plan

Read the full prompt before writing any code. The examples table is the question. Every method call and result tells you something concrete. For example, if a table shows c1.takeOrder(2) returning "Order number 1, cost $3.5", that single line tells you the class tracks order numbers (starting at 1), calculates costs, and formats a specific string.

Then ask one question: what information persists between method calls? If the number of cupcakes goes down after each order and the order number goes up, those are your instance variables. Jot them down with types before you write the class.

Minutes 6-10: Header, instance variables, constructor

This part should feel mechanical if you planned well.

Write the class header exactly as the question names it. Declare every instance variable private, with descriptive names that echo the problem ("availableCupcakes", not "c").

For the constructor, the call in the examples tells you the signature. If the table shows new CupcakeMachine(10, 1.75), your constructor takes an int and a double, in that order. Parameter names are up to you; types and order are not. Initialize every instance variable in the constructor body, including ones that aren't parameters. A counter that starts at 1 still needs to be set to 1 somewhere.

Minutes 11-18: Write the method(s)

Trace the examples to build your logic. Most FRQ 2 methods follow the same three-part flow:

1. Check whether the action is valid (are there enough cupcakes?).
2. Perform the action (calculate the cost).
3. Update the state (decrease inventory, increment the counter).

When validation fails, steps 2 and 3 never happen. That's why the examples almost always show a failure case like takeOrder(10) on a machine with 5 cupcakes returning "Order cannot be filled". The conditional check is being tested directly.

If string formatting is fighting you, get the logic right first and come back to the string. Logic and return value are scored as separate points, so sound logic with a slightly-off string still earns the algorithm point.

Minutes 19-22: Trace and fix

Mentally run every row of the examples table through your code. Does each call produce exactly the output shown? Does the counter increment only on success? Does every path through the method return something?

Warning signs: if you hit minute 15 and haven't started the method, stop polishing the constructor and move on. A mostly-right constructor plus a working method beats a perfect constructor with no method. If you're at minute 20 with code that won't compile, stop adding anything and fix syntax.

Worked Example: CupcakeMachine

Here's what a complete answer looks like for a typical Class Design scenario. Suppose the question describes a cupcake vending machine created with new CupcakeMachine(10, 1.75) (10 cupcakes at $1.75 each), where `takeOrder(2)` returns "Order number 1, cost$3.5" and an order larger than the remaining inventory returns "Order cannot be filled". This is an editorial example of the pattern, not an official released question, but it mirrors the structure exactly:

</>Java
public class CupcakeMachine
{
    private int numCupcakes;
    private double price;
    private int orderNumber;

    public CupcakeMachine(int cupcakes, double cupcakePrice)
    {
        numCupcakes = cupcakes;
        price = cupcakePrice;
        orderNumber = 1;
    }

    public String takeOrder(int amount)
    {
        if (amount > numCupcakes)
        {
            return "Order cannot be filled";
        }
        double cost = amount * price;
        numCupcakes -= amount;
        String result = "Order number " + orderNumber + ", cost $" + cost;
        orderNumber++;
        return result;
    }
}

Notice the details the rubric cares about. All three instance variables are private. The order number is initialized to 1 in the constructor even though it's not a parameter. The validity check comes first, and a failed order returns immediately without touching any state. The order number only increments after a successful order, and the result string is built before the increment so it shows the right number. Every path returns a String.

Key Patterns in Class Design Questions

FRQ 2 reuses the same handful of design moves, so recognizing them turns a new problem into a familiar one.

Tracking object state. Almost every Class Design question involves state that changes over time: inventory shrinks, scores grow, bookings fill up. Instance variables hold the state; methods modify it. When the prompt says calling one method changes how a later call behaves, that's your cue that an instance variable updates in between. This is the whole point of object-oriented programming, and it's exactly what the question tests.

Counter variables. Order numbers, turn counters, transaction IDs. These almost always start at 1 (not 0) and increase only when an operation succeeds. Incrementing a counter on a failed operation is one of the most common ways to lose the logic point.

Conditional success and failure. If the examples show both a normal result and an error message, your method needs an if/else with returns on both paths. Even when the prompt says "assume all values passed are positive," you still need the inventory check, because the examples show it failing.

Formatted output. Strings like "Order number 1, cost $3.5" are testing concatenation. The pattern is fixed text + variable + fixed text + variable. Use +, and remember numbers convert to strings automatically when concatenated. Don't overthink it, and copy the punctuation and spacing exactly.

Common Mistakes

• Making instance variables public. The rubric checks for private. Write private in front of every instance variable as a reflex, every time.
• Starting a counter at 0 or incrementing on failure. Match the examples: if the first successful order is "Order number 1", initialize to 1 and only increment inside the success branch.
• Printing instead of returning. System.out.println(result) earns nothing if the method is supposed to return a String. The examples table shows return values, so write return.
• A path with no return. If your if branch returns but your else case doesn't, the return-value point is gone. Trace every possible path and confirm each one returns.
• Adding features nobody asked for. Input validation beyond what the examples show, extra methods, fancy formatting. None of it earns points, and any of it can introduce errors that lose points. If the prompt says "assume all values are positive," believe it.
• Mismatching the constructor signature. If the example shows new CupcakeMachine(10, 1.75), an (double, int) constructor loses the header point. Copy the types and order straight from the example call.

Practice and Next Steps

The fastest way to improve at FRQ 2 is repetition with feedback: write full classes under a 22-minute timer, then check every rubric point against your code. Start with Fiveable's FRQ practice with instant scoring to see exactly which points you're earning, and pull more prompts from the AP CSA FRQ question bank and past exam questions.

Class Design is one of four FRQ types, and the skills overlap. The method-writing habits here carry directly into FRQ 1: Methods and Control Structures and FRQ 3: Data Analysis with ArrayList. When you're ready to simulate the real thing, take a full-length AP CSA practice exam and see where your score lands.