Identifies excessive method chaining as a code smell, signaling a need to refactor to reduce coupling and improve encapsulation.

Alerts developers that the code may be overly coupled and could benefit from introducing intermediary objects or delegating methods.

When code contains expressions like object.getPart().getComponent().doWork() where each intermediate object is only used to navigate to the next.

Object-oriented codebases, especially those with deep object hierarchies, insufficient encapsulation, or overuse of getters.

object.getX().getY().doSomething()

object.method().method()...

object, method1, method2, ..., methodN

• get
• get
• get
• do
• process
• handle
• compute

• Introduce an intermediate object
• extract method
• use delegation
• apply Law of Demeter

Assuming chaining is always acceptable, ignoring coupling issues, overusing getters instead of telling objects what to do

Law of Demeter, Train Wreck anti-pattern, Fluent interfaces (intentional chaining), Builder pattern

May be confused with intentional fluent interfaces or builder patterns where chaining is deliberate and readable

• Code Smells
• Law of Demeter
• Encapsulation

Not all method chaining is problematic; fluent interfaces and builders are designed for readability and are intentional.

Encourages refactoring towards better encapsulation, reducing dependencies and improving maintainability.

Think of a train wreck of method calls.

Distinguish unintentional message chains from intentional fluent interfaces to avoid false positives.

Refactor to eliminate message chains using Introduce Intermediate Object or Extract Method.