Define abstractness (A) for a component, and explain the "main sequence" A + I = 1, the distance metric D = |A + I - 1|, and what the zone of pain and zone of uselessness are.

### Abstractness ``` A = Na / Nc Na = number of abstract classes + interfaces in the component Nc = total number of types in the component ``` "Abstract" means a type that cannot be instantiated and exists to be implemented/extended — an interface, abstract class, protocol, trait, or (in dynamic languages) a documented duck-typed contract. A = 0: purely concrete. A = 1: nothing but contracts. Why would abstractness matter? Because of the **Open–Closed Principle**: a component that others depend on should be extendable without being modified. Extension without modification requires abstractions to extend. So the more depended-upon a component is, the more of its public surface should be abstract. ### The main sequence Plot every component on a square with I on the x-axis and A on the y-axis. Two corners are trouble: - **(0, 0) — the Zone of Pain.** Maximally stable *and* maximally concrete. Everything depends on it, and there is no abstraction through which to vary it. Changing it is a system-wide edit; extending it is impossible without modification. Real examples: a concrete database schema, a concrete `Utils` class used by every module, a rigid serialized data format, a concrete framework base class. Note the nuance: some inhabitants of this zone are *fine* because they are **non-volatile** — a `String` type, a stable math library, a well-known standard library. Pain only bites when a zone-of-pain component actually changes. - **(1, 1) — the Zone of Uselessness.** Maximally abstract and maximally unstable: abstractions nobody depends on and (often) nobody implements. This is leftover speculative generality — interfaces created "in case we need another implementation" that never arrived. It is dead weight and should be deleted or inlined. The line joining (0, 1) and (1, 0) — that is, **A + I = 1** — is the **main sequence**. Points on it are balanced: fully stable components are fully abstract; fully unstable components are fully concrete; middling components are partly both. ### Distance ``` D = | A + I - 1 | (range 0..1, 0 = on the line) D' = | A + I - 1 | / sqrt(2) (true perpendicular distance, some tools use this) ``` A component with A = 0.0 and I = 0.1 has D = 0.9 — deep in the zone of pain. A component with A = 0.9, I = 0.9 has D = 0.8 — deep in uselessness. A component at A = 0.4, I = 0.7 has D = 0.1 — fine. Aggregate uses: mean D over the codebase as a rough architectural-health trend line; per-component D sorted descending as a refactoring backlog. ### Related principles - **Stable Abstractions Principle (SAP)**: *a component should be as abstract as it is stable.* This is literally the main sequence restated. Together with the Stable Dependencies Principle (depend toward lower I), SAP is the component-level restatement of the Dependency Inversion Principle: high-level policy is stable and abstract; low-level detail is unstable and concrete. ### How to move a component off the line — the actual refactorings - **Stuck at low A, low I (pain):** extract interfaces for the depended-upon behavior, move them into an abstraction component, and have dependents import the abstractions. Or accept it if the component is genuinely frozen. - **Stuck at high A, high I (uselessness):** delete the unused abstractions, or collapse the interface into its single implementation. "One interface, one implementation, forever" is the classic tell. - **Concrete component that everything depends on because it holds shared data structures:** consider whether the types belong to a shared kernel (accepted, low volatility) or whether each consumer should own its own model. ### Caveats you should voice in an interview 1. **Language dependence.** A is easy to compute in Java/C#/Kotlin; in Python, Go, JavaScript, or Rust the notion of "abstract type" maps imperfectly (Go interfaces are structural and usually declared by the *consumer*; Python has ABCs and Protocols; TypeScript interfaces vanish at runtime). Report the counting convention. 2. **Interfaces are not free.** Chasing A upward produces one-implementation interfaces, indirection, and harder navigation. D is a smell detector; near-zero D is not a goal. 3. **It ignores volatility.** The metric cannot tell an inert concrete component from a churning one. Combine D with change frequency from version-control history — high D **and** high churn is where to act. 4. **Goodhart's law.** The moment D becomes a KPI, teams add empty interfaces to game it.