How does Tell, Don't Ask differ from the Law of Demeter, and why does fixing a "train wreck" like `a.getB().getC().doThing()` by adding delegating methods sometimes make the design worse?

## Definitions **Law of Demeter (LoD)**, formulated at Northeastern University for object-oriented style, also called the *principle of least knowledge*. In its common object form, a method `m` of object `O` may only invoke methods of: 1. `O` itself, 2. `m`'s parameters, 3. objects `m` creates, 4. `O`'s direct component objects (fields), 5. (often added) globals/singletons accessible to `O`. What it forbids is calling methods on the *return value* of another call - the "one dot" heuristic (imprecise, but memorable). `a.getB().getC().doThing()` is a **train wreck**. **Tell, Don't Ask (TDA)**: if a decision depends on an object's data, that object should make it. TDA is about *responsibility*; LoD is about *reach*. ## Why they overlap A train wreck is usually a symptom of ask-style code: the caller navigates the graph precisely because it wants data to decide with. So the same line trips both rules. But they are not equivalent: - LoD violation without TDA violation: `config.getSection("db").getString("url")` - deep navigation, but no decision stolen from anyone. Coupling to structure is the only cost. - TDA violation without LoD violation: `if (order.getStatus() == DRAFT) order.setStatus(SUBMITTED)` - a single dot each, perfectly Demeter-legal, and still the wrong owner for the decision. ## The middleman failure mode Mechanically satisfying LoD by delegation: ``` class Order { String getCustomerZip() { return customer.getAddress().getZip(); } } // caller: if (order.getCustomerZip().startsWith("9")) applyWestCoastRate(); ``` The dots are gone; the design is not better: - The **decision still lives in the caller** - TDA is untouched. - `Order` grows one forwarding method per caller need - the *middle man* smell; its API becomes a projection of everybody's queries. - Coupling is now hidden rather than removed: `Order` still depends on Address's shape, and every caller depends on Order's swelling surface. - Refactoring tools and reviewers stop seeing the chain, so the real problem is camouflaged. ## The better move Ask *what is the caller trying to accomplish?* and name that: ``` Money tax = order.calculateTax(rateTable); // Order asks its own customer/address order.shipWith(carrier); // Order tells its collaborators ``` Or introduce the missing concept: if many callers need zip-based rules, the concept is a `ShippingZone` value object that owns them. Now the chain is gone because nobody needs to navigate, and the middle object gained *behavior*, not forwarding. Other legitimate resolutions: - **Pass the collaborator in** (dependency injection / parameter object) instead of navigating to it. - **Move the method** to the class at the end of the chain (Move Method), the classic feature-envy fix. - **Publish an event or callback** so the far object reacts instead of being fetched. ## Deliberate exceptions - **Fluent interfaces / builders**: `builder.a().b().c()` returns the same object; there is no graph navigation. - **Stream/collection pipelines and immutable value chains**: `text.trim().toLowerCase().split(",")` - pure transformations over values with no hidden state to protect. - **Data structures / DTOs / config trees**: these exist to be traversed; LoD's rationale (protecting behavior and invariants) does not apply. - **Test builders and assertions**, where readability outranks coupling. ## Practical guidance 1. Treat a train wreck as a *question*, not a defect: what decision is being assembled here? 2. If the answer names a domain operation, move the operation (TDA fix). 3. If there is no decision - just data plumbing at a boundary - a projection method or DTO is fine, and adding behavior would be wrong. 4. Only add a delegating accessor when it expresses a genuine concept of the middle object (`order.shippingZone()`), never one per caller. 5. Watch cohesion metrics/reviews for classes that are all one-line forwarders - that is the middleman accumulating.