AP CSA FRQ 1 and 2: Methods and Class Design Without Getting Lost

FRQ 1 and FRQ 2 usually go wrong before the first line of code

Students often think they lost AP CSA free-response points because their Java was not fancy enough.

Usually that is not the real problem.

The real problem starts earlier:

• they did not read the spec carefully
• they confused fields with parameters
• they started writing before deciding what the method had to return
• they solved a nearby problem instead of the actual one

FRQ 1 and FRQ 2 reward clean translation from English to code.

What these two FRQs are actually asking for

FRQ 1: Methods and Control Structures

This question usually asks you to write one or two method-sized chunks of code that follow a very specific contract.

That often means:

• use a loop or conditional
• call existing methods from the class
• build or return the right result
• match the examples in the prompt

FRQ 2: Class Design

This question asks you to build a class from a specification.

That usually means:

• define private fields
• write a constructor
• write required methods
• make each method use the stored object state correctly

Neither question is supposed to be a giant software project. They are structured, small, and point-sensitive.

Start with a translation pass

Before you code, write a quick checklist from the prompt.

For a method question, ask:

• What are the parameters?
• What must the method return?
• What must the method change, if anything?
• What loop or conditional is probably needed?

For a class-design question, ask:

• What data belongs in fields?
• What data belongs only in method parameters?
• What must the constructor initialize?
• Which methods read the fields, and which modify them?

This sounds basic. It is where a lot of points are won.

A fast FRQ 1 example

Suppose the prompt says:

• write a method that counts how many numbers in an array are even
• return the count as an int

The clean outline is:

public int countEvens(int[] nums) {
    int count = 0;
    for (int i = 0; i < nums.length; i++) {
        if (nums[i] % 2 == 0) {
            count++;
        }
    }
    return count;
}

Before worrying about the exact code, notice the structure:

• an accumulator
• a loop through the array
• a condition
• a return at the end

That is what FRQ 1 often looks like.

The most useful FRQ 1 habit: write the skeleton first

When the prompt is method-based, write the bones before the details:

• method header
• variable setup
• loop or conditional shell
• return statement

That keeps you from wandering.

For example, if you know the method must:

• inspect each element
• test a condition
• count or total something

then you already know the broad form.

You can fill in the specific method calls after that.

Common FRQ 1 mistakes

Returning the wrong thing

Students write logic that almost works, then return the loop variable or print the result instead of returning the actual answer.

Ignoring the method contract

If the method is supposed to modify an object, do not build a separate throwaway value and return that.

If the method is supposed to return a value, do not just change a field and stop.

Losing a boundary case

The method works for the middle of the data but breaks on:

• an empty array
• the first item
• the last item
• a case where no values match

That is why the examples in the prompt matter so much.

FRQ 2 is mostly about keeping object state clean

FRQ 2 can look more formal than it really is.

The prompt is usually giving you a small model:

• what the object stores
• how it gets initialized
• what each method should do

The biggest trap is mixing together three different things:

• instance variables
• constructor parameters
• local variables inside methods

If those blur together, the class gets messy fast.

A fast FRQ 2 example

Suppose the prompt wants a Book class with:

• a private title
• a private pages
• a constructor
• a getTitle method
• an isLong method

The basic shape is:

public class Book {
    private String title;
    private int pages;

    public Book(String title, int pages) {
        this.title = title;
        this.pages = pages;
    }

    public String getTitle() {
        return title;
    }

    public boolean isLong() {
        return pages > 300;
    }
}

Notice what makes this clean:

• fields are private
• constructor stores the incoming values
• methods use the fields
• no extra clutter

That is usually enough.

The most useful FRQ 2 habit: decide fields versus parameters on purpose

Ask one question:

Does this piece of data belong to the object after the method finishes?

If yes, it is probably a field. If no, it is probably a parameter or a local variable.

That one test prevents a lot of awkward class-design mistakes.

For example:

• a book’s title belongs to the object
• a temporary counter inside one method usually does not

Common FRQ 2 mistakes

Forgetting this in the constructor

If the parameter has the same name as the field, this matters.

public Book(String title) {
    title = title;
}

That line only assigns the parameter to itself. The field never changes.

Writing methods that ignore the object’s state

If the method should use the stored fields, do not accidentally create new local variables that replace the real job.

Overcomplicating the class

FRQ 2 does not reward “enterprise Java.” It rewards matching the spec.

If the prompt wants three fields and three methods, do that well. Do not invent extra architecture.

A simple protocol for FRQ 1 and FRQ 2

Use this every time.

1. read the full prompt once without coding
2. underline what must be returned or changed
3. list the fields, parameters, and helper information already given
4. write the method or class skeleton
5. fill in the logic line by line
6. test the examples in the prompt mentally before moving on

That protocol is not glamorous. It is how you stop leaking easy points.

What to check before you leave the question

For FRQ 1:

• Did I return the required value?
• Did I use the right loop bound?
• Did I handle the no-match case correctly?

For FRQ 2:

• Are the fields really fields?
• Does the constructor initialize them?
• Do the methods use the object’s stored state?

If you only have thirty seconds left, those checks are still worth doing.

The real goal

FRQ 1 and FRQ 2 do not ask you to be brilliant. They ask you to be exact.

If you can translate the prompt, build the skeleton, and keep fields, parameters, and return values from blurring together, these two questions become much more manageable.