How Objects Collaborate

Collaboration in an object-oriented system happens through messages. One object holds a reference to another and calls a method on it, and each object is responsible only for its own state. The system becomes a network of objects that each know a little about a few others.

public class Main {
    public static void main(String[] args) {
        Cart cart = new Cart();
        cart.add(new Book("Effective Java", 45.0));
        cart.add(new Book("Clean Code", 38.5));
        cart.checkout(new CashPayment());
        System.out.println("total = " + cart.total());
    }
}

class Cart {
    private final java.util.List<Book> items = new java.util.ArrayList<>();
    void add(Book b) { items.add(b); }
    double total() {
        double sum = 0;
        for (Book b : items) { sum += b.price(); }
        return sum;
    }
    void checkout(Payment payment) { payment.pay(total()); }
}

class Book {
    private final String title;
    private final double price;
    Book(String title, double price) { this.title = title; this.price = price; }
    double price() { return price; }
}

interface Payment {
    void pay(double amount);
}

class CashPayment implements Payment {
    public void pay(double amount) { System.out.println("paid " + amount); }
}

The example shows the three roles. The cart owns the books and knows how to total them. The payment is a collaborator the cart uses for one operation, and it arrives from outside through the method argument. The cart does not know which payment it will use, so a different one can be passed in with no change to the cart. The output shows the checkout happening and the total being reported separately.

The design rule that keeps this manageable is that every collaborator should have one job. The cart knows about books and about the payment contract, and it delegates. It does not know how to format money, how to persist an order or how to send a receipt, because those belong to other objects.

The way this goes wrong is when objects start reaching into each other. If the cart reached into the payment's fields, or if the order service called methods on the book's internals, the network would become a mesh where every object knows about every other. The defences are small collaborating objects, narrow interfaces, and passing collaborators in rather than constructing them inside.

A collaboration is easy to follow when the relationships form a tree or a shallow graph, when each link goes through a narrow interface, and when each object has a single responsibility. A reader can then follow one message at a time and know what the receiver will do with it.

It becomes a tangle when the graph gets dense, when objects navigate through each other to reach a third object, and when the direction of the calls is hard to predict. The classic signs are a service that reaches into a repository's internals, a domain object that calls back into a service that created it, and a method that takes five objects because it is doing five unrelated things.

The cause is usually misplaced responsibility. When one object ends up needing information from three others to answer a question, the information should be gathered by one of them, or the question should be split. The rule of one knowledge per object is the practical heuristic: each piece of information lives in exactly one place, and other objects ask for it rather than fetching it themselves.

The remedies are structural. Inject the collaborators so the direction of dependency is visible. Keep interfaces narrow so each link is easy to follow. Give objects behaviour instead of exposing their data, so a collaborator cannot reach past an object to something it should not touch. And watch for cycles, which usually mean two responsibilities have been merged and need splitting.