6 Interfaces and Abstractions

The purpose of abstraction

An abstraction focuses attention on what a component can do rather than on every detail of how it does it. This creates a separation between a public contract and an implementation.

For example, a notification client may require only the ability to send a message. It should not need to know whether the message is delivered by email, text message, or another mechanism. Several unrelated classes can provide that capability through the same contract.

This separation is valuable when implementations may change, when infrastructure should be isolated from business logic, or when tests need substitute components.

Takeaway: Depend on stable capabilities, not on details that are likely to vary.

Interfaces as focused contracts

An interface defines required behavior without normally prescribing how that behavior is implemented. A client can accept an interface-typed parameter and call the promised operation without selecting a particular concrete class.

A class may implement several interfaces, which allows one object to support independent capabilities. For instance, a document, photograph, and map could all implement a Printable interface even though they do not belong to the same conceptual class hierarchy.

In a nominal type system, a class explicitly declares that it implements an interface. In a structural type system, a type qualifies when it has the required members. Structural subtyping is the name for this latter relationship; it is also associated with static duck typing.

An interface is strongest when it is cohesive and small. If unrelated clients need different operations, splitting one large interface into focused interfaces usually produces clearer dependencies.

Takeaway: Use an interface to express a meaningful capability or boundary, especially when unrelated types may provide that capability.

Abstract classes and related families

An abstract class is an incomplete class intended to serve as a base for related concrete classes. It may contain abstract members that subclasses must provide, concrete members that supply shared behavior, and state or protected operations used by that shared behavior.

An abstract class is useful when subclasses share more than a capability. For example, a report-exporting base class could format a report and control the overall export process while leaving the format-specific output operation to concrete subclasses.

Interfaces and abstract classes both express contracts, but they emphasize different relationships:

• Use an interface when the capability may apply to unrelated classes.

• Use an interface when one class needs several independent capabilities.

• Use an abstract class when subclasses form a closely related family.

• Use an abstract class when subclasses should share state, construction rules, invariants, or substantial implementation.

• Use an abstract class when the base class should control part of an algorithm.

Inheritance should not be chosen solely to reuse a small piece of code. If an object needs a formatter, policy, or service, composition and dependency injection may communicate the design more clearly.

Takeaway: Choose an interface for a capability and an abstract class for a related family that shares implementation or state.

Polymorphism across implementations

Polymorphism allows one client to work with multiple concrete types through the same abstraction. A function that calculates totals for priced items can rely only on a promised pricing operation; the items might be books, subscriptions, or service plans.

The client remains unchanged while each concrete object calculates its result differently. The appropriate implementation is selected for the actual object at runtime.

This approach reduces conditional logic based on concrete class names. Instead of asking which kind of object has been supplied and branching for each case, the client invokes the operation defined by the abstraction.

Implementation is the concrete type that fulfills the abstraction's contract. For polymorphism to be reliable, implementations must satisfy not only the required signatures but also the expected semantics, including relevant error behavior and invariants.

Takeaway: Polymorphism lets clients depend on stable behavior while concrete implementations vary.

Dependency direction and injection

A direct concrete dependency can make a high-level component difficult to replace or test. If an order service constructs one specific payment gateway internally, it becomes tied to that vendor, construction process, and possibly network behavior.

Dependency inversion changes the design direction: important application logic depends on a payment abstraction, while a concrete gateway implements that abstraction. Dependency injection supplies the gateway from outside the service.

The supplied implementation can be a production gateway in the application or a fake payment gateway in a test. The service can therefore be tested in isolation without changing its business logic.

A layered design can follow this pattern:

• The user interface calls an application service.

• The application service depends on a repository abstraction.

• A database-specific repository implements that abstraction.

This arrangement improves replaceability, testability, maintainability, and modularity. It also keeps database drivers, SQL details, and vendor-specific behavior outside the business logic.

Takeaway: Let high-level policy depend on contracts and supply infrastructure implementations at the boundary.

Designing useful abstractions

Programming to abstractions means expressing a component's real requirements with the most general useful type. A function that only needs to iterate over documents should accept an iterable document abstraction rather than a particular array-list implementation.

A practical design process is:

1. Identify what the client actually needs.

2. Define a small contract for those operations.

3. Make concrete types fulfill the contract.

4. Pass implementations into the client.

5. Keep implementation-specific details outside the client.

Do not create an abstraction merely because every class is expected to have one. An abstraction earns its place when it represents a meaningful variation, capability, boundary, or dependency. An interface with too many members is difficult to implement, while one with too few meaningful members may not help clients.

A contract includes more than method names and parameter types. For a cache, clients may need to know whether a missing key produces a special result or an exception, whether values are copied or referenced, whether access is thread-safe, and what happens when storage is full. Matching signatures do not guarantee matching behavior.

Takeaway: Keep abstractions focused, behaviorally precise, and independent of unnecessary technology details.

Putting the principles together

Interfaces and abstract classes provide different ways to separate contracts from implementations. Interfaces emphasize capabilities that may cross unrelated class hierarchies, while abstract classes support related types that share state or algorithmic structure.

Polymorphism makes those contracts useful at runtime: clients can work with different implementations without changing their own logic. Dependency inversion and dependency injection extend the same idea across architectural boundaries, keeping application policy independent from infrastructure.

A durable abstraction should be:

• Small enough for clients and implementers to understand.

• Meaningful enough to support realistic implementations.

• Explicit about important semantics and error behavior.

• Free from unnecessary database, framework, file-format, or vendor details.

• Tested with more than one realistic implementation when the contract is intended to support variation.

The central design question is not whether a class should have an interface. It is whether the client needs a stable, meaningful contract that separates required behavior from changeable implementation details.