FRQ 2 – Class Design

Overview

• FRQ2 is the Class Design question, worth 7 points (about 11.2% of free-response score, roughly 5% of total exam score)
• Budget 20-22 minutes (out of 90 minutes for all four FRQs)
• Unique aspect: you're writing an entire class from scratch - not just methods or filling in blanks

FRQ2 follows a consistent structure. They'll describe some real-world object (like a vending machine, a game, or a reservation system) and tell you exactly how it should behave. They'll give you a table showing method calls and their expected outputs. Your job? Write the complete class that makes all those examples work perfectly.

Strategy Deep Dive

Writing a complete class from scratch might seem daunting, but the graders have structured this question to be systematic and fair. They want to see if you can translate real-world requirements into working code - a fundamental programming skill. Here's the most effective approach:

FRQ2 reflects authentic programming tasks. When you're asked to model a vending machine or a reservation system, you're doing exactly what software developers do every day - taking a real-world concept and translating it into code. The test makers deliberately choose familiar scenarios so you can focus on the programming concepts rather than trying to understand some obscure problem domain.

Begin with a complete read-through - don't skip this step. The examples table at the end? That's gold. It tells you exactly what your class needs to do. Look at the CupcakeMachine example - they show you that c1.takeOrder(2) returns "Order number 1, cost $$3.5". From this single line, you can deduce that your class needs to track order numbers (starting at 1), calculate costs, and format strings in a specific way.

This systematic process works well:

Step 1: Identify what you need to track Look at every method call in the examples. What information persists between calls? In CupcakeMachine, the number of cupcakes decreases after each order, and the order number increases. These need to be instance variables.

Step 2: Plan your instance variables Don't just think about data types - think about names. Use descriptive names that match the problem description. If they talk about "available cupcakes," name your variable availableCupcakes or numCupcakes, not just c. And here's crucial: make them private. Always. The rubric specifically looks for this.

Step 3: Write the constructor The constructor parameters tell you what initial information the class receives. Initialize every instance variable here. Don't forget variables that aren't in the parameters - like order numbers that start at 1. Think about the "state" your object needs to be in when it's first created.

Step 4: put in place the methods This is where the examples table becomes your best friend. Trace through each example mentally. When takeOrder(10) is called on a machine with only 5 cupcakes, it returns "Order cannot be filled". This tells you there's a conditional check. When an order succeeds, three things happen: cupcakes decrease, order number increases, and a formatted string is returned. Build your logic to handle every case shown.

Edge case handling distinguishes top scores: Even though the problem says "assume all values passed to takeOrder are positive," you still need to handle the case where there aren't enough cupcakes. The rubric explicitly checks for this. Also, the order number should only increment when an order succeeds - if you increment it for failed orders too, you'll lose points.

Rubric Breakdown

Breaking down each of the 7 points and what graders actually look for:

Point 1: Class Header (1 point) This seems trivial, but students lose this point more than you'd think. Write public class ClassName exactly as specified. Not private class, not class public. If they show CupcakeMachine in the examples, that's your class name. Case matters. Also, no code outside the class brackets - everything goes inside.

Point 2: Instance Variables (1 point) Graders check three things here: Are they private? Are they the right types? Did you declare all necessary variables? From the CupcakeMachine example, you need an int for cupcake count, a double for price, and an int for order number. Missing any of these or making them public loses the point. Static variables? Automatic loss. Declaring them inside a method instead of at class level? Loss.

Point 3: Constructor Header (1 point) Match the parameter types exactly as shown in the examples. If they show new CupcakeMachine(10, 1.75), your constructor needs (int something, double something). The names don't matter, but the types and order do. Don't make it private.

Point 4: Constructor Body (1 point) Every instance variable must be initialized correctly. This is where students often trip up with the order number - it should start at 1, not 0. The graders are surprisingly lenient here though. If you initially set order number wrong but fix it before returning the first string, you can still earn this point.

Point 5: Method Header (1 point) Look at how methods are called in the examples. c1.takeOrder(2) tells you the method is public, returns something (check what type from the output), is named takeOrder, and takes an int parameter. Get any part wrong, lose the point.

Point 6: Method Logic/Algorithm (1 point) This is the big one. Your method must handle all cases correctly: orders that can be filled, orders that can't, updating instance variables appropriately. The graders check your overall algorithm here. Even if your string formatting is slightly off, you can still earn this point if your logic is sound. But forget to check if enough cupcakes are available? Point gone.

Point 7: Return Value (1 point) You must return the appropriate string in all cases. The graders are picky about this - you can't just print the string, you must return it. If your method sometimes doesn't return anything (like forgetting the else case), you lose this point even if everything else is perfect.

Students often think they need to validate input or add extra features. Don't. If the problem says "assume all values are positive," believe them. Adding unnecessary validation won't earn extra points but could introduce errors that lose points.

Key FRQ2 Patterns

FRQ2 questions reveal consistent patterns that feel almost like the test makers are following a secret playbook. Once you recognize these patterns, you'll approach each new problem with confidence because you'll realize you've essentially solved it before.

Tracking Object State Almost every class design question involves tracking state that changes over time. Vending machines track inventory, games track scores, reservation systems track bookings. The key insight? Instance variables hold the state, methods modify it. When you see "after calling method X, subsequent calls to method Y should behave differently," that's your cue that instance variables are being modified.

At a deeper level: the College Board uses this pattern because it tests whether you truly understand object-oriented programming. Objects aren't just containers for methods - they're entities that maintain state and behave differently based on that state. This is fundamentally different from procedural programming where functions always produce the same output for the same input. When you recognize this pattern, you're not just solving a problem - you're demonstrating that you understand the very essence of OOP.

Counter Variables Look for anything that increments: order numbers, player turns, transaction IDs. These almost always start at 1 (not 0!) and increase only on successful operations. If an operation fails, counters don't increment. This trips up so many students who increment counters unconditionally.

Method Structure Most methods follow this flow: First, check if the action is valid (enough cupcakes?). Then, perform the action (calculate cost). Finally, update the state (decrease cupcakes, increment order number). Methods that return error messages always have this structure - the validation fails, so the action and update never happen.

Formatted Output When they want formatted output like "Order number 1, cost $$3.5", they're testing if you can concatenate properly. The pattern is always: fixed text + variable + fixed text + variable. Don't overthink it. Use + for concatenation, and remember that numeric values automatically convert to strings when concatenated.

Time Management Reality

Allocate the initial 5 minutes to understanding and planning. I know it feels like forever when you're not writing code, but this investment pays off. Spend this time identifying instance variables and understanding the examples.

Minutes 6-10: Write your class header, instance variables, and constructor. This should be mechanical if you planned well. Don't second-guess yourself here.

Minutes 11-18: put in place the main method(s). This is where you'll spend most of your time. If you're stuck on string formatting, just get the logic right first. You can always come back to fix strings.

Minutes 19-22: Review and test. Mentally trace through each example. Does your code produce the right output? Did you handle the edge cases?

Watch for these warning signs: If you hit minute 15 and haven't started the main method, you're behind. Skip perfecting the constructor and move on. A constructor that mostly works plus a perfect method beats a perfect constructor with no method. If you're at minute 20 with code that doesn't compile, stop adding features. Fix syntax errors first.

How to distinguish productive work from wasted effort: Productive time is writing code that directly addresses the examples. Spinning wheels is adding fancy features they didn't ask for or obsessing over variable names. When you catch yourself thinking "wouldn't it be cool if...", stop. They give you exactly what they want in the problem description.

Keep in mind: FRQ2 becomes straightforward when you approach it systematically. The classes are always reasonable - data containers with methods that perform clear operations. Follow the examples methodically, and those 7 points are yours.

FRQ2 stands out because it mirrors actual software development. You're taking a real-world concept and implementing it as a class - exactly what programmers do daily. The skills you show here aren't just for the AP exam; they're the foundation of actual software development. Master this question type, and you're not just earning exam points - you're proving you can think like a programmer.