Orphan abstraction

What it means

An orphan abstraction is an interface, base class, service, or helper whose purpose is unclear or whose original consumers have disappeared. It can preserve obsolete assumptions and force readers to navigate indirection. Before removal, teams should confirm dynamic use, generated references, and documented extension contracts.

Example

A base formatter has one subclass and no active registration path after a migration. The team traces configuration and release artifacts, then removes it with a focused test update.

Limitations

An abstraction may be intentionally reserved for a plugin ecosystem or external consumer. Usage search alone can miss reflective loading. Record the evidence and ownership decision before simplifying.

How to use the signal

If removal is unsafe, mark the abstraction’s owner and supported extension contract instead of leaving its purpose implicit.

Search configuration, plugins, and generated references before removal, then record why the abstraction is no longer needed.

Weave can show whether abstraction cleanup reduces review complexity or later rework. The repository and runtime configuration establish liveness; Weave supplies delivery context.