Interface
An interface is a contract that declares which operations must exist while leaving the implementation of those operations to concrete types. Callers can depend on the contract rather than on one class name and its internals.
βΆArchitecture Diagram
π RelationshipDashed line animations indicate the flow direction of data or requests
When calling code is tightly coupled to a specific class, changing storage strategy, integration details, or test setup often forces the upper layer to change too. That coupling also makes it harder to substitute test doubles or alternate implementations.
Large object-oriented systems repeatedly needed to support several implementations of the same role: in-memory storage versus file storage, production service versus test double, and so on. Interface-driven design spread because it offered a stable role boundary across those differences.
An interface usually defines only method names and input/output shapes. Multiple classes can implement that contract, and callers need to know only that the contract is satisfied, not which concrete class is underneath.
Interfaces and abstract classes both create common surfaces, but interfaces focus on the contract itself while abstract classes also carry shared implementation. If you want a lightweight role boundary without shared code, an interface is the simpler tool.
Interfaces fit roles such as notifier, storage adapter, or payment gateway where the responsibility stays the same but implementations may change. If there is only one concrete implementation and little realistic chance of substitution, introducing an interface too early can add ceremony without real flexibility.