Skip to content

Interface-Based Programming

A component architecture in which clients depend on abstract interfaces, obtain implementations through factories or registries, and avoid direct cross-component use of concrete classes so implementations can be substituted behind stable contracts.

Version
v1 · 2026-09-28 · History
Domain-specific #
10092
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomains
Software Architecture, Object Oriented Design → Computer Science & Software Engineering

Core Idea

Interface-based programming makes abstract interfaces the only allowed APIs across software components and obtains hidden implementations through factories, registries, or injection so they can be substituted. This pattern was especially valuable in languages whose package systems did not enforce component modules, such as Java before Java 9, and remains useful when separate teams or third parties supply plugins. This pattern was especially valuable in languages whose package systems did not enforce component modules, such as Java before Java 9, and remains useful when separate teams or third parties supply plugins.

Scope of Application

The pattern is used in plugin platforms, enterprise components, testable services, device adapters, persistence layers, GUI tools, SDKs, and legacy object-oriented systems. Use it with component boundary, interface semantics, hidden implementations, binding/lifecycle, data/error contracts, versioning, allowed dependencies, and tests for cohesion, coupling, and substitutability explicit.

  • Plugins. Loads third-party implementations under stable contracts.
  • Testing. Substitutes fakes or alternate adapters.
  • Team boundaries. Separates ownership and release cadence.
  • Infrastructure adapters. Hides databases, messaging, or devices.
  • Legacy modularization. Creates enforceable seams before a module migration.

Clarity

State component ownership, public interfaces, behavioral pre/postconditions, data types, version policy, factory/binding mechanism, lifecycle, thread/error semantics, allowed dependencies, and whether runtime or build-time enforcement exists. The closest near miss sets the boundary: Dependency inversion is the nearest principle; interface-based programming is a concrete component architecture implementing it. A positive case must satisfy this test: An architecture qualifies when cross-component calls and object acquisition are constrained to abstract contracts and concrete realizations remain substitutable/hidden.

Manages Complexity

The pattern narrows visible dependencies and localizes implementation change. It also adds indirection, contract maintenance, binding configuration, and debugging across abstractions; poorly chosen interfaces merely move complexity. The central substitutability–implementation-specific capability tradeoff is this: A narrow contract enables replacement while hiding useful optimizations. A second decoupling–indirection tension matters because Factories remove constructors from clients while complicating tracing. The stable API–evolution tension adds that Clients need continuity while interfaces must change with requirements.

Abstract Reasoning

Use three linked moves: choose cohesive component boundaries from responsibilities, not class counts; define minimal behavioral interfaces around consumer needs; hide implementations and route creation through an abstract binding mechanism. As a collapse test, the case exits when clients cast to implementations, import concrete types, depend on undocumented behavior, or factories expose implementation-specific lifecycle. A fourth check is to enforce dependency direction with build/module checks and contract tests. A final check is to evolve versions while testing substitutability and avoiding leaky shared state.

Knowledge Transfer

Contract-mediated substitution transfers across services and hardware adapters, but interface-based programming specifically concerns component APIs and implementation hiding in software architecture. No canonical parent prime is currently asserted; broader structural comparisons remain related-prime analogies until separately adjudicated in the DAG. Concrete representation is hidden behind a public contract. Multiple implementations can occupy one client-visible role.

Relationships to Other Abstractions

Local relationship map for Interface-Based ProgrammingParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Interface-BasedProgrammingDOMAINDomain-specific abstraction: Software-Architecture Style — is a kind of, conditionalSoftware-Archit…DOMAIN

Current abstraction Interface-Based Programming Domain-specific

Parents (1) — more general patterns this builds on

  • Interface-Based Programming is a kind of, conditional Software-Architecture Style Domain-specific

    Supported when abstract interfaces govern cross-component dependencies system-wide, not when only one local interface is used.

    Condition / exception Supported when abstract interfaces govern cross-component dependencies system-wide, not when only one local interface is used.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Interface-Based Programming sits in a crowded region of the domain-specific corpus (38th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Software & Systems Architecture (29 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08