Association: Uses-A

Before You Start

Check each box you can do from memory. A box you cannot check yet is not a problem; it points you to a quick refresher, not a grade.

• I can state what syntactic element in a Java class establishes a HAS-A relationship.
• I can name the keyword that establishes an IS-A Is Inheritance relationship in Java.
• I can describe how long a method parameter remains in scope.

Try This First

public class Sorter {
    public void sort(final Player[] arr, final Comparator<Player> cmp) {
        Arrays.sort(arr, cmp);
    }
}

Before reading: does Sorter HAS-A Comparator<Player>? Why or why not?

What You Need To Walk In With

The Insight: Association is the weakest form of object relationship. It is “uses-a” rather than “has-a.” The marker is where the type appears: a method parameter or a local variable (association) versus a field (HAS-A). Most uses of types in code are associations, not HAS-A; the class does not own or store the object, it merely receives and uses it for one call. The ability to trace where a type reference lives in a class declaration (field, parameter, or local) is what separates a confident reader of unfamiliar code from a confused one.

You can: identify any type reference in a class as IS-A, HAS-A, or association; state why a method parameter cannot be HAS-A; spot the anti-pattern of stashing a parameter into a field; and classify every type reference in a worked example before checking the answer.

How It Works

What association looks like

public class BankTeller {
    public Receipt processWithdrawal(final Customer customer, final int amount) {
        // customer is in scope only for this method call
        // BankTeller does not "have a" Customer permanently
        return new Receipt(customer.getId(), amount);
    }
}

BankTeller USES-A Customer during one transaction. The customer existed before the call and persists after it. No field stores the customer. This is association.

The distinction: where the type appears

Why parameters are not HAS-A

HAS-A is a structural relationship encoded in field declarations. It persists across method calls: the same Engine field is still there after accelerate() returns. A parameter exists only during one invocation. When processWithdrawal returns, customer is gone. No state is retained between calls.

Quick check

Worked Example: Predict Then Check

public class FraudCheck {
    private final RulesEngine rules;         // (a)

    public FraudCheck(final RulesEngine rules) {
        this.rules = rules;                  // (b)
    }

    public boolean isValid(final Customer c) {  // (c)
        List<Rule> applicableRules = rules.getRulesFor(c.getCountry()); // (d)
        return applicableRules.stream().allMatch(r -> r.passes(c));
    }
}

For each marked item, state the relationship type: IS-A, HAS-A, or association.

Common Misconceptions

Misconception: storing a method parameter into a field opportunistically

Wrong mental model: “I’ll save the customer reference into a field during this call so the next method can use it.”

Why it breaks: Stashing a parameter into a field silently changes the relationship from association to aggregation. The class’s state now depends on a reference whose lifetime it did not declare itself responsible for. The caller may modify or discard the object, and the class will see those changes unexpectedly.

How to correct: If a class genuinely needs to remember a reference across calls, declare a field with that intent in the class declaration. Make the dependency explicit. If the relationship is truly transient, accept it as a parameter on every call that needs it.

Source: Bloch, Effective Java, Item 17.

Quick check

Formal Definition

UML 2.5 defines association as a structural relationship between two or more types where objects of one type are connected to objects of the other. In Java, the weakest form of association is the “uses” dependency: a type appears in a method signature or local variable but is not stored as a field.

Mental Model

Think of association as borrowing. A bank teller borrows your debit card for 30 seconds to process a transaction. The teller does not own the card; the teller does not keep it; after the transaction, the card goes back to you and the teller has no record of which card it was. That borrowing relationship is association. HAS-A (aggregation or composition) is more like owning: the object is kept in a drawer after the interaction.

Connections

Within CSCD 210/211: Every Arrays.sort(arr, cmp) call in the comparator material is an association: the sort method uses the comparator for one call, does not store it.

Looking back: The prior lesson on IS-A Is Inheritance distinguished IS-A from HAS-A. This lesson introduces the weakest form of the “uses” relationship that sits below HAS-A.

Looking ahead: Aggregation: Has-A, Can Outlive covers the first true HAS-A form, where the contained object is received from outside and can outlive the container.

Go Deeper (optional)

None of this is needed to write correct code today. It is here for the curious reader who wants to know where these ideas connect to the wider world of software.

Association is so common that it is effectively invisible in daily coding: every method parameter in Java is an association. That ubiquity is why it rarely gets its own arrow in a UML diagram unless it carries a meaningful name or multiplicity. In professional design reviews and architecture documents, though, the three relationship types (association, aggregation, composition) each have their own UML arrow, and reading them correctly is a standard expectation. A junior developer who can look at a class diagram and immediately classify every connector is prepared for technical design discussions in a way that takes some engineers years to develop.

The lifetime distinction matters beyond diagram conventions. When you trace a parameter through a method call, you are reasoning about object lifetime: who created the object, who is responsible for it while the method runs, and who owns it after the method returns. That kind of thinking is the foundation of correct memory management, thread-safety reasoning (a shared mutable Customer passed as a parameter to two concurrent tellers is a race condition), and API contract design (a method that accepts a Customer parameter promises not to retain it, which the caller relies on). Knowing the vocabulary makes it easier to read and write those contracts clearly.

In professional Java codebases, the discipline of not promoting a parameter to a field without declaring the intent upfront traces directly to the single-responsibility idea that David Parnas formalized in 1972: a module should know only what it needs to know, and “stashing” a reference is a covert way of expanding what the module knows.

Practice

Level 1

Classify each relationship:

// (a)
class PrintService {
    public void print(final Document doc, final Printer p) { ... }
}

// (b)
class PrintService {
    private final Printer printer;
    public PrintService(final Printer printer) { this.printer = printer; }
}

Level 2

In S20.Lab2.CSCD211Lab2Methods, most methods have signatures like menu(Scanner kb) and printPersons(Person[] arr, PrintStream ps). The class has no instance fields. What is the relationship between CSCD211Lab2Methods and Person?

Level 3

A student adds this field to BankTeller after seeing a method that receives a Customer:

private Customer lastCustomer;

public Receipt processWithdrawal(final Customer customer, final int amount) {
    this.lastCustomer = customer;   // stash for later
    ...
}

Explain what changed and what problems this introduces.

Check Yourself

Close the notes and answer each one from memory, then reveal it. Pulling an idea back from memory is one of the strongest ways to make it stick.