Mutable Object in AP Computer Science A

In AP Computer Science A, a mutable object is an object whose state (the values of its instance variables) can be changed after it is created. Because Java passes object references, a method that receives a mutable object can alter the original object.

What is Mutable Object?

A mutable object is an object whose state can change after it's built. In CED terms, an object's state is its attributes and their values at a given time, stored in its instance variables (EK 3.4.A.1). If any method can change those values after the constructor runs, the object is mutable. An ArrayList is the classic example, because add, remove, and set all change what's inside it. A class you write with setter methods is mutable too.

Mutability gets tricky because of how Java handles objects. A variable never holds the object itself. It holds an object reference, which is basically the object's address. When you pass a mutable object to a method, the parameter gets a copy of that address, not a copy of the object (EK 3.6.A.1). So two variables can point at the same object, and a change made through one shows up through the other. That's the whole reason mutability gets its own spot in the CED.

Why Mutable Object matters in AP® Computer Science A

Mutable objects live in Unit 3: Class Creation, specifically Topics 3.4 (Constructors) and 3.6 (Accessor Methods). They support two learning objectives:

• 3.4.A asks you to declare instance variables and initialize them in constructors. EK 3.4.A.3 addresses what to do when a constructor receives a mutable object as a parameter. The instance variable should hold a copy of that object, so the new object isn't secretly sharing data with the caller.
• 3.6.A asks you to determine the result of calling methods that use object references. EK 3.6.A.1 says a method can use a reference parameter to alter a mutable object, and it's good practice not to do that unless the specification requires it. EK 3.6.A.2 adds that returning an object reference returns the reference, not a new copy.

The big idea here is encapsulation. If your class hands out or stores raw references to mutable objects, outside code can change your object's private state without going through your methods.

How Mutable Object connects across the course

Immutable Object (Units 1, 3)

This is the mirror image. A String is immutable, so methods like toUpperCase() hand you back a brand-new String and leave the original alone. Sharing a reference to an immutable object is harmless. Sharing a reference to a mutable one is how bugs sneak in.

Object References and Parameters (Unit 3)

Passing an object to a method is like handing someone a copy of your house key, not a copy of your house. They can't swap out your key, but they can walk in and rearrange the furniture. With a mutable object, the furniture really does get rearranged.

Constructors and Instance Variables (Unit 3)

When a constructor stores a mutable parameter directly (like songs = s;), the new object and the caller now share one list. Making a copy instead (like songs = new ArrayList<String>(s);) gives the object its own independent state, which is what EK 3.4.A.3 recommends.

Accessor Methods Returning References (Unit 3)

A getter that returns a mutable instance variable returns a reference to the real thing, not a copy (EK 3.6.A.2). So even a "read-only" accessor can let outside code modify your private data.

Is Mutable Object on the AP® Computer Science A exam?

Mutable objects show up mostly in multiple-choice code-tracing questions. Typical stems look like these:

• "Which of the following statements about object references passed as method parameters is true?"
• "Which of the following is an example of a mutable object in Java?"
• "A method receives a reference to a mutable object as a parameter. What can happen inside the method?"
• A class like Playlist with a constructor that takes an ArrayList<String> parameter, followed by "what is printed?" after the original list is changed.

What you need to do:

1. Classify objects. ArrayList and arrays are mutable. String is immutable.
2. Trace aliasing. If two variables refer to the same mutable object, a change through either one is visible through both.
3. Spot the copy (or the lack of one). Check whether a constructor stores the parameter directly or builds a new copy, then predict the output.

No released FRQ has used the term "mutable object" verbatim. Still, the idea matters on Class Design FRQs, where you write constructors and methods that initialize and update instance variables correctly.

Mutable Object vs Immutable Object

The question is whether the object's state can change after construction. A mutable object (like an ArrayList) can be modified in place, so every reference to it sees the change. An immutable object (like a String) can't be modified. Any method that looks like it changes the object actually returns a new object. A common trap is s.toUpperCase(); on its own line. It doesn't change s at all unless you write s = s.toUpperCase();, which points s at a new String.

Key things to remember about Mutable Object

• A mutable object is one whose instance variable values can be changed after the constructor finishes running.

• When you pass an object to a method, Java copies the reference, not the object, so the method can change the original mutable object.

• ArrayList objects and arrays are mutable, while String objects are immutable.

• A constructor that receives a mutable object should store a copy of it, so the new object doesn't share state with the caller.

• Returning a mutable instance variable from an accessor returns a reference to the real object, which can break encapsulation.

• It's good programming practice not to modify a mutable object passed as a parameter unless the specification asks you to.

Frequently asked questions about Mutable Object

What is a mutable object in Java for AP CSA?

A mutable object is an object whose state, meaning the values of its instance variables, can be changed after it's created. In AP CSA, the key example is ArrayList, which you can modify with methods like add, remove, and set.

Is a String a mutable object?

No. A String is immutable, so methods like substring or toUpperCase return a new String and never change the original. This is one of the most commonly tested contrasts with mutable objects like ArrayList.

Does passing an object to a method create a copy of the object?

No. The parameter gets a copy of the reference, so it points to the same object as the argument (EK 3.6.A.1). If that object is mutable, changes made inside the method show up in the original object after the method returns.

What's the difference between a mutable and an immutable object?

A mutable object (like an ArrayList) can be changed in place after creation. An immutable object (like a String) can't, and any "change" produces a new object. That's why sharing references to mutable objects can cause unexpected side effects, while sharing references to immutable ones is safe.

Why should a constructor copy a mutable parameter instead of storing it directly?

If the constructor writes songs = s;, the object and the caller share one list, so outside code can change the object's private state. Writing songs = new ArrayList<String>(s); gives the object its own independent copy, which is the approach EK 3.4.A.3 describes.