What Is Abstraction?

Abstraction is the practice of describing what a component does without describing how it does it. The interface is its expression in Java: a named set of operations that says what callers can rely on and nothing more. A concrete class also has an abstraction, but it comes with an implementation attached, so callers end up depending on both the contract and the details.

public class Main {
    public static void main(String[] args) {
        Storage store = new FileStorage();
        store.write("hello");
        System.out.println(store.read());
        Storage other = new FileStorage();
        other.write(" world");
        System.out.println(store.read());
    }
}

interface Storage {
    void write(String text);
    String read();
}

class FileStorage implements Storage {
    private String content = "";
    public void write(String text) { content = content + text; }
    public String read() { return content; }
}

The output shows the two things an interface gives you. First, the reference type lets callers depend on the contract, so the same code can be pointed at a different implementation later without changing the caller. Second, the abstraction is enforced by the compiler, so a class that does not honour the contract cannot be used where the interface is expected.

The second point is where the interface really earns its keep. A caller written against Storage cannot accidentally depend on something FileStorage happens to have, because those extra methods are not visible through the interface. The contract is what the compiler checks and what the caller sees.

The cost to name honestly is that you have designed a promise. Every implementation has to honour it, and adding a method to the interface later breaks every implementor. That is a good reason to keep interfaces small and to add a second, focused interface rather than widening an existing one.

Because an interface describes behaviour without providing any of it. It has no fields to initialise and no method bodies to run, so there is nothing for an instance to contain. Attempting it is a compile error, and the message says that Storage is abstract and cannot be instantiated.

public class Main {
    public static void main(String[] args) {
        // Storage store = new Storage();   // will not compile: interface
        Storage store = new FileStorage();
        store.write("hello");
        System.out.println(store.read());
    }
}

interface Storage {
    void write(String text);
    String read();
}

class FileStorage implements Storage {
    private String content = "";
    public void write(String text) { content = content + text; }
    public String read() { return content; }
}

What you do instead is write a class that implements the interface, and then create an instance of that class. The variable is typed as the interface while the object is a concrete implementation, which is exactly the arrangement that lets the caller stay ignorant of the details.

There are two related shapes worth mentioning. An abstract class can also not be instantiated, but it can hold state and provide concrete methods, so subclasses inherit real behaviour from it. A functional interface, one with a single abstract method, can be implemented with a lambda expression, so you can produce an instance without writing a named class at all.

The design point behind the rule is worth stating: the compiler refusing to build an abstract type is a feature, because it stops you from creating an object that has no defined behaviour. If you want a default implementation, write one and make it concrete.

Leakage happens when the contract mentions implementation concepts. If an interface called Storage declared a method that returned a java.io.File, the abstraction is already broken, because callers now depend on the storage being file based. The same happens when a method takes or returns a concrete collection type, when a parameter is named after an implementation detail, or when the interface is described in terms of one strategy rather than the capability.

The first defence is to type the contract in domain terms and use the most general type that expresses the requirement. A method that returns a List is fine; one that returns an ArrayList is not. A method that accepts a Collection is fine; one that demands a specific implementation is not. This is usually called programming to the interface rather than to the implementation, and it is mostly a question of what types appear in the signatures.

The second defence is to watch for exceptions and side effects that reveal the mechanism. An interface that throws a SQL exception, or whose methods are documented in terms of rows and columns, has leaked regardless of its types.

The third defence is behavioural. If the abstraction can be implemented in genuinely different ways, then the contract is probably right. A capability that can only ever be implemented one way is not an abstraction, it is a description of a class, and the honest move is to say so and use the class directly.