Topic 3.6 Notes – Methods: Passing and Returning References of an Object

1. How Object References Work in Method Calls

You already know Java is pass-by-value. The key is understanding what gets copied.

• Primitive variable → the actual value is copied
• Object variable → the reference (memory address) is copied
• The object itself is never duplicated automatically

When you pass an object to a method, the parameter receives a copy of the reference, so both variables point to the same object in memory. That situation is called aliasing.

Picture the stack and heap like this:

Aliasing: two references to the same array object

Both nums (in the caller) and arrParam (in the method) point to the same array object in the heap.

That leads to two very different outcomes depending on what the method does:

public static void change(int[] arr) {
    arr[0] = 50;        // modifies the object
    arr = new int[3];   // reassigns the parameter
}

After calling change(nums):

• arr[0] = 50 → persists, because it changed the shared object.
• arr = new int[3] → does not affect nums, because only the local parameter was reassigned.

When you trace these on a quiz, ask yourself:

• Did the method change the object’s contents?
• Or did it just reassign the parameter?

Only the first one affects the caller.

2. Modifying Mutable Objects Through Parameters

Most objects you use in AP CSA are mutable, meaning their state can change after creation.

Common mutable types:

• Arrays
• ArrayList
• Custom classes with setters

If a method receives a reference to one of these, it can:

• Modify fields
• Change array elements
• Add/remove from an ArrayList

Those changes remain after the method ends because the object itself was changed.

When this is appropriate

If the method’s purpose is clearly to modify:

• addItem
• removeStudent
• sortScores

That’s expected behavior.

When this becomes a problem

If a method sounds like it should just compute something:

public static double average(ArrayList<Integer> list)

But inside it removes elements or reorders them, that creates an unexpected side effect.

Good practice on the AP exam:

• Do not modify parameter objects unless the method’s job requires it.
• If you need to modify for calculation, copy first:

ArrayList<Integer> copy = new ArrayList<Integer>(list);

A very common mistake on MCQs is assuming the list was copied automatically. It wasn’t.

3. Returning Object References

When a method returns an object, it returns the reference, not a new object.

public ArrayList<String> getNames() {
    return names;
}

The caller now holds a reference to the same internal list.

That can create a privacy leak.

Example:

getNames().clear();

Now the class’s private list has been wiped out from outside the class. That breaks encapsulation.

How to prevent privacy leaks

The safest AP-level solution is returning a defensive copy:

public ArrayList<String> getNames() {
    return new ArrayList<String>(names);
}

Now the caller gets a separate list.

This shows up constantly in FRQ class design. If a getter returns a mutable instance variable directly, graders often treat that as a design flaw.

Remember:

• Returning an object → returns the reference.
• No automatic copying happens.

4. Accessing Private Data of Parameters

Here’s a rule students forget:

A method can access private fields of a parameter only if the parameter is the same type as the class.

Example:

public class Account {
    private double balance;

    public void merge(Account other) {
        this.balance += other.balance;  // allowed
    }
}

This works because both objects are Account. A class can access private members of other objects of its own type.

But this will not compile:

public void process(Loan loan) {
    loan.balance;   // error if balance is private in Loan
}

You must use a public method like loan.getBalance().

This matters for:

• Copy constructors
• Comparison methods
• Transfer-style methods

If the parameter type is different, private data stays inaccessible.

5. How to Trace Reference Questions on the Exam

When you see object parameters, draw arrows. For example:

Reference tracing with aliasing

Both list1 and list2 point to the same ArrayList object. When that list is passed into a method, the parameter temp points to that same object as well. No new object is created. Only the reference is copied.

Step-by-step when tracing:

1. Draw each variable as an arrow to an object.
2. On method call, draw the parameter arrow pointing to the same object as the argument.
3. Track:
   • Field/element changes → affect original
   • Parameter reassignment → local only

Common AP patterns:

• Array passed in and modified
• ArrayList getter returning internal list
• Two variables assigned to same object (b = a)
• Method reassigns parameter and students think it affects original

If you clearly track which variables point to which objects, these questions become mechanical instead of confusing.