Train wreck anti-pattern

TL;DR

• A train wreck is a chain like order.getCustomer().getAddress().getCity() where each dot crosses an object boundary, coupling the caller to the internal structure of every type in the chain.
• The Law of Demeter says: only talk to your immediate neighbors. Do not navigate through friends to reach strangers.
• Each link in the chain is a dependency. If Address is refactored to Location, every chain touching .getAddress() breaks.
• The fix is delegating methods: order.getShippingCity() hides the chain behind a single call on the nearest object.
• Fluent APIs and builder chains are NOT train wrecks because they return the same object, not progressively deeper objects.

The Problem

Your ShippingService calculates delivery costs. To get the customer's city and shipping zone, it navigates through Order to Customer to Address:

public class ShippingService {
    public ShippingQuote calculateShipping(Order order) {
        // 3-level chain: Order -> Customer -> Address
        String city = order.getCustomer().getAddress().getCity();
        String zone = order.getCustomer().getAddress().getShippingZone();
        String country = order.getCustomer().getAddress().getCountry();

        // 2-level chain: Warehouse -> Location
        String warehouseRegion = closestWarehouse.getLocation().getRegion();

        return rateCalculator.quote(city, zone, country, warehouseRegion);
    }
}

This method depends on five classes: Order, Customer, Address, Warehouse, and Location. The method signature says it needs an Order, but at runtime it reaches three levels deep. When the team renames Address to ContactInfo or nests Address inside a ShippingDetails wrapper, every chain breaks.

I've debugged a refactoring where moving Address from Customer to a new ShippingProfile class caused 47 compilation errors across 12 services, all from train wreck chains.

The method "reaches through" each object to get to the next. Every intermediate type becomes a compile-time dependency that the caller should never have known about.

Why It Happens

1. Object graph navigation feels natural. Developers think in terms of the domain: "an order has a customer who has an address." Translating that directly to code produces chains.
2. Getters expose the graph. If Customer has getAddress() and Address has getCity(), chaining them is the path of least resistance. The getter API invites deep navigation.
3. Delegation feels like boilerplate. Writing order.getShippingCity() that delegates to customer.getShippingCity() that delegates to address.getCity() feels like useless indirection, until a refactoring proves its value.
4. Flat service classes. In anemic-model codebases, services do all the work and entities are pure data holders. The service must navigate the graph because the entities offer no behavior.

How to Detect It

The Fix

Add delegating methods at each level so callers only talk to their immediate neighbor. Each object exposes the information callers need without revealing its internal structure.