Skip to main content

What does "depend on abstraction, not on implementation" mean?

The phrase "depend on abstraction, not on implementation" means that a module should work through an interface or an abstract contract, not through the concrete class that does the work. In other words: the client should know what the dependency does, but should not know how it does it.

In detail:

1. An abstraction is a contract (an interface / a base class)

An abstraction defines the set of methods guaranteed by any implementation. It describes behavior, not a specific way of carrying it out. Example of an abstraction:

python
class NotificationChannel: def send(self, msg): raise NotImplementedError

2. An implementation is a concrete class that does the work

It knows how to send:

python
class EmailChannel(NotificationChannel): def send(self, msg): print("Email:", msg)

3. The client should depend only on the abstraction

Wrong:

python
def notify_user(): channel = EmailChannel() # depends on the implementation channel.send("hello")

Right:

python
def notify_user(channel: NotificationChannel): channel.send("hello") # depends on the abstraction

4. Why this matters

  • it allows any implementation to be supplied without changing the client code;
  • it simplifies testing (a mock or fake implementation can be supplied);
  • it reduces coupling and makes the architecture more flexible;
  • it allows infrastructure to change without rewriting the business logic.

5. A sign of correct architecture

All high-level code depends only on interfaces. Low-level details implement these interfaces and can be freely replaced.

Summary: Depending on the abstraction means relying on the contract. Not depending on the implementation means not being tied to the concrete ways of fulfilling that contract. This is the foundation of DIP and one of the main principles of flexible architecture.

Short Answer

Interview ready
Premium

A concise answer to help you respond confidently on this topic during an interview.