Code quality and technical debt

Interface segregation

Also known as Interface segregation, Interface segregation in software engineering

By WeavePublished 1 min read

Definition

A design principle that favors focused interfaces so clients depend only on what they use.

What it means

Interface segregation reduces the obligation for a client to know about methods irrelevant to its work. Smaller, role-specific contracts can lower coupling and make substitutions and tests easier. The principle is about useful responsibility boundaries, not maximizing the number of interfaces.

Example

A document exporter needs write and close, but it receives a large storage interface with deletion, indexing, and administration methods. A focused writer contract narrows what the exporter can depend on.

Limitations

Over-segregation can create a maze of tiny abstractions and make common workflows harder to discover. A shared interface may be appropriate when operations form one coherent capability. Judge by client needs and change patterns.

How to use the signal

Prefer contracts that match client responsibilities, while avoiding tiny interfaces that make the common path harder to discover.

Weave can help compare interface refactors with review size and rework. Keep the design decision with the team, using Weave to see whether the narrower contract reduces delivery friction.

How this relates to Weave

Weave can help compare interface refactors with review size and rework. Keep the design decision with the team, using Weave to see whether the narrower contract reduces delivery friction.

Explore Engineering intelligence

Sources and further reading

  1. SonarSource code metrics and analysis documentation