Code quality and technical debt

Abstractness metric

Also known as Abstractness metric, Abstractness metric in software engineering

By WeavePublished 1 min read

Definition

A measure of how many types in a component are abstract rather than concrete.

What it means

Abstractness compares abstract types, such as interfaces or abstract classes, with total types in a component. It can help describe whether a package primarily defines contracts or implementations. Used with instability, it supports architectural conversations about dependency direction and zones that may be difficult to change.

Example

A package with many interfaces and few concrete classes may be designed as a boundary for multiple implementations. A neighboring package with only concrete adapters may be intentionally implementation-focused. The pair suggests questions about ownership and change direction.

Limitations

The metric does not judge whether abstractions are useful. Excess interfaces can add indirection, while concrete code can be the clearest choice in a small stable area. Language features and generated types can distort counts.

How to use the signal

Weave can place abstraction changes next to pull request review patterns and rework. Keep the calculation tied to a known language parser and package boundary, then use those delivery signals to decide whether the architecture is helping the team.

How this relates to Weave

Weave can place abstraction changes next to pull request review patterns and rework. Keep the calculation tied to a known language parser and package boundary, then use those delivery signals to decide whether the architecture is helping the team.

Explore Engineering intelligence

Sources and further reading

  1. SonarSource code metrics and analysis documentation