In AP Computer Science A, private is a Java access modifier that restricts a variable or method so only code inside the same class can use it; the AP CSA course convention is that all instance variables are declared private to enforce encapsulation.
Private is one of Java's access modifiers, the keywords that control who is allowed to touch a class member. When you mark a variable or method private, only code written inside that same class can read it, change it, or call it. Code in any other class, including a subclass, gets a compile-time error if it tries.
Think of a class as a house. Public methods are the front door, the official way in. Private instance variables are the stuff inside the house. Visitors don't get to rummage through your drawers; they knock on the door and ask. That "ask through a method" pattern is encapsulation, and it's the whole reason private exists. In AP CSA, the convention is strict: instance variables are always private, and the outside world interacts with them only through public methods like getters, setters, and constructors.
Private is the mechanism behind encapsulation, one of the central object-oriented design ideas in AP CSA's class-writing units. The course convention (and the FRQ scoring expectation) is that instance variables are declared private and accessed through public methods. Private also drives a huge amount of inheritance reasoning. A subclass does not get direct access to its superclass's private variables, which is exactly why subclass constructors must call super(...) instead of assigning inherited fields directly. If you've ever wondered why Car can't just write make = "Toyota"; when make lives in Vehicle, the answer is one word: private.
Keep studying AP Computer Science A Unit 3
Encapsulation (Class Writing)
Private is how you actually implement encapsulation in Java. Encapsulation is the design principle (hide the data, expose behavior), and the private keyword is the tool that does the hiding.
Public / Access Modifiers (Class Writing)
Private and public are two settings on the same dial. AP CSA's rule of thumb is simple: instance variables get private, and the methods other classes need to call get public.
Inheritance and super (Inheritance Unit)
A subclass inherits private variables in the sense that the object stores them, but it cannot touch them by name. That forces subclass constructors to call super(...) to initialize them, a setup the exam tests constantly.
Mutable Objects (References)
Watch the leak. If a getter returns a reference to a private mutable object (like an ArrayList), outside code can change its contents anyway. Private protects the variable, not necessarily the object it points to.
On the multiple-choice section, private shows up in inheritance questions. A classic setup gives you a superclass like Vehicle with private fields make and year, then a subclass Car, and asks which constructor compiles. The trap answer assigns the superclass's private variables directly from the subclass, which doesn't compile. The correct answer calls super(make, year). Related stems test what Java inserts when a subclass constructor omits super (an implicit call to super()).
On the FRQs, private is everywhere even when the question isn't "about" it. Released questions like 2017's Digits and Phrase classes hand you private instance variables, and you're expected to work with them through methods. When a class-design FRQ asks you to write a full class (like 2017 Q2's StudyPractice implementation), declare your instance variables private. Writing them public violates the course's encapsulation convention and can cost you points.
Public means any class anywhere can access the member; private means only code inside the declaring class can. They're opposite ends of Java's visibility settings. The AP CSA pattern pairs them: private data, public interface. Mixing this up on a class-design FRQ (public instance variables) is one of the most common self-inflicted point losses.
Private restricts access to a variable or method so only code inside the same class can use it.
In AP CSA, instance variables are always declared private, and other classes reach them through public getter, setter, and constructor methods.
A subclass cannot directly access its superclass's private variables, so subclass constructors must call super(...) to initialize them.
If a subclass constructor doesn't explicitly call super, Java automatically inserts a no-argument super() call as the first line.
Private is the keyword that implements encapsulation; encapsulation is the design idea, private is the enforcement.
On class-design FRQs, declaring instance variables public instead of private violates the expected convention and can lose points.
Private is an access modifier that limits a variable or method to the class it's declared in. No other class, not even a subclass, can access it directly. In AP CSA, all instance variables follow this convention.
No, and this is a top MCQ trap. The subclass's objects still store those variables, but the subclass code can't read or assign them by name. It has to go through the superclass's constructor (via super) or its public methods.
Public members are accessible from any class; private members are accessible only within their own class. The AP CSA pattern is private instance variables paired with public methods, so the class controls exactly how its data gets used.
Yes. When an FRQ asks you to design or complete a class, declare instance variables private. It's the encapsulation convention the scoring guidelines expect, and public instance variables can cost you the point for declaring fields correctly.
No. Private controls who can access the variable, not whether it can change. The class's own methods can still modify private data, and a public setter can let outsiders change it indirectly. If you want a value that never changes, that's the final keyword, a different tool entirely.