ADP

Acyclic Dependencies Principle

“Allow no cycles in the component dependency graph.” – Robert C. Martin

If Component A depends on B, B depends on C, and C depends on A, you have a cycle. This is bad.

When to use

When designing the dependency graph of your modules/packages.

Why it matters

  • Builds: You can’t build A without B, B without C, and C without A. Infinite loop.
  • Testing: To test A, you need B and C linked in. You can’t test components in isolation.

Signs of Violation

  • “Morning After Syndrome”: You go home, code works. You come back, code is broken because someone changed a dependency that unknowingly cycled back to you.
  • You have to deploy the entire system at once; you can’t update just one part.

Explanation

Problem

Cycles turn distinct components into one giant “mega-component”. They defeat the purpose of modularity.

Solution

Break the cycle.

  1. Apply DIP: Create an interface in the middle.
  2. Create a new component that both depend on.

Real world analogy

Chicken and Egg. Which comes first? If you need both to start, you can’t start.

Pros and Cons

Pros Cons
  • Modularity
  • Buildable systems
    		•
  • Requires vigilance (cycles sneak in)
    		•

    Comparison

    • DIP: DIP is the primary tool to break cycles.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)