Most “legacy code” isn’t legacy because it’s old.
It’s legacy because it has lost its agency.
I’ve worked with millions of lines of production code over four decades, across some of the largest companies in the world. The pattern is always the same:
Objects don’t manage their own state
Behavior is scattered
Changes ripple unpredictably
Teams are afraid to touch the code
This isn’t a tooling problem.
It isn’t an Agile problem.
It isn’t even a testing problem.
It’s a modeling problem.
The Core Distinction: Assertive vs. Inquisitive
One of the most useful distinctions I know is this:
Assertive code acts.
Inquisitive code asks questions and acts elsewhere.
Assertive objects:
own their responsibilities
protect their invariants
change state as a result of behavior
Inquisitive objects:
pull data out of other objects
make decisions on their behalf
coordinate behavior they don’t own
When code becomes inquisitive, objects stop being entities and start behaving like subroutines with getters.
And this is where the Law of Demeter enters the conversation.
Demeter Is Not About Style — It’s About Agency
The Law of Demeter is often taught as a stylistic rule:
“Only talk to your immediate friends.”
That framing misses the point.
Demeter is a canary.
When it’s violated, something deeper is usually wrong.
Breaking Demeter often means:
objects are no longer responsible for themselves
callers are short-circuiting the system
behavior is being orchestrated procedurally
In other words: agency has been stripped away.
The Getter/Setter Trap
Many developers don’t experience getters and setters as a problem.
They feel harmless. Clean. Explicit.
But getters and setters are often how procedural thinking leaks into object-oriented code.
Instead of asking an object to do something, we:
pull out its state
make a decision elsewhere
push new state back in
That’s not object interaction — it’s manual state manipulation.
A useful metaphor here:
If someone wants to buy a candy bar from me,
it isn’t appropriate for me to reach into their pocket
and check how much money they have.
That’s their responsibility — not mine.
When we break Demeter, we shift responsibilities away from where they belong. Objects lose meaning. Systems lose structure.
Why This Becomes Hard to Refactor
Demeter violations are some of the hardest problems to unwind.
Why?
Because they don’t create one dependency.
They create many small, invisible ones.
This is why refactoring techniques like the Mikado Method exist — because restoring agency often requires touching large portions of a system safely and incrementally.
But when agency is restored, something remarkable happens:
tests become simpler
behavior becomes localized
systems become changeable again
Teams stop firefighting and start building.
Agency Scales Beyond Code
There’s a reason this matters beyond software design.
When code has agency, teams have agency.
When systems are coherent, organizations become coherent.
I’ve seen Conway’s Law work in reverse: well-structured systems reshape how people collaborate.
Demeter isn’t just a design rule — it’s a signal that we’re modeling reality with respect.
Closing: Reframe the Purpose
Object-oriented programming isn’t about classes.
It’s about creating entities that can take care of themselves.
When we respect that idea, code becomes expressive, resilient, and humane.
When we don’t, everything collapses into a procedural tangle — no matter what language we’re using.
And that’s why the Law of Demeter still matters.
