Abstraction in Real Systems

Abstraction shows up at the boundaries where a component meets something that will change: a notification channel, a payment gateway, a storage engine, a clock, a random source. Those are the places where you want a named contract so the rest of the system does not have to be rewritten when the choice behind it changes.

public class Main {
    public static void main(String[] args) {
        Notifier notifier = new ConsoleNotifier();
        notifier.notifyUser("build finished");
        notifier = new CountingNotifier(new ConsoleNotifier());
        notifier.notifyUser("deploy started");
    }
}

interface Notifier {
    void notifyUser(String message);
}

class ConsoleNotifier implements Notifier {
    public void notifyUser(String message) { System.out.println("notify: " + message); }
}

class CountingNotifier implements Notifier {
    private final Notifier delegate;
    private int count;
    CountingNotifier(Notifier delegate) { this.delegate = delegate; }
    public void notifyUser(String message) {
        count++;
        delegate.notifyUser(message);
    }
    public int count() { return count; }
}

The counting notifier is the pattern to point at. It implements the same contract as the console notifier and wraps another notifier, adding behaviour without changing it. That is possible only because the interface exists. Before you had the interface, adding a counter meant editing the notifier class and every place that used it.

Introducing an abstraction incrementally is easier than it sounds. Write the interface with the methods the current implementation already has, make the existing class implement it, and change the callers to depend on the interface type rather than the concrete class. None of that changes behaviour, so it can be done in small reviewable steps. Once the seam exists, the second implementation, in this case a real email or push notifier, is a small addition.

The discipline that keeps this from turning into abstraction for its own sake is to add an interface when you can name the second implementation or the test double you need, not before. An interface with exactly one implementation forever is a layer that costs indirection and buys nothing.

A payment gateway is the standard example. The caller calls charge with an amount and a token, and receives a result. Behind that one call sits retry logic with backoff, tokenisation of card details, idempotency keys, a choice between two providers, a sandbox mode, and error translation into a small set of failure categories. The caller knows none of that and does not need to.

A file system API is another. The caller opens a file and reads lines without knowing whether it is reading from disk, from memory, from an object store, or from a compressed archive. The interface is the promise that these behave the same way.

Third, a clock. Code that reads the current time through an injected time source is testable, because the test supplies a fixed clock. If code called the system clock directly, the abstraction would be missing and every timing test would need to sleep and hope.

What makes these abstractions work is the same in each case: the contract is expressed in the vocabulary of the caller rather than of the implementation, and the complexity genuinely varies behind it. A wrapper with one implementation and no variation is only a layer.