Abstraction

1. What Is It?

Abstraction is the OOP principle of exposing only what a component does — its interface and behavior — while hiding how it does it. A caller interacts with an abstraction without needing to know the underlying implementation details.

Without abstraction, every caller is coupled to implementation specifics. Change the implementation and every caller breaks. With abstraction, you define a stable contract (a class interface or method signature), and implementations can vary freely behind it. This is the mechanism that makes code replaceable, testable, and extensible.

2. How It Works

1. Define the contract — an abstract class or interface declares what operations exist, with no implementation (or minimal shared logic).
2. Implement concretely — one or more concrete classes fulfill the contract by providing the actual behavior.
3. Program to the abstraction — callers depend on the abstract type, not the concrete class. At runtime, a concrete instance is injected or created, but the caller never changes.

Mermaid Diagram

-+ResetFullscreen

Python

Copy
from abc import ABC, abstractmethod
import math


class Shape(ABC):
    @abstractmethod
    def area(self) -> float:
        """Return the area of the shape."""
        ...

    @abstractmethod
    def perimeter(self) -> float:
        """Return the perimeter of the shape."""
        ...

    def describe(self) -> str:
        return f"{type(self).__name__}: area={self.area():.2f}, perimeter={self.perimeter():.2f}"


class Circle(Shape):
    def __init__(self, radius: float) -> None:
        self._radius = radius

    def area(self) -> float:
        return math.pi * self._radius ** 2

    def perimeter(self) -> float:
        return 2 * math.pi * self._radius


class Rectangle(Shape):
    def __init__(self, width: float, height: float) -> None:
        self._width = width
        self._height = height

    def area(self) -> float:
        return self._width * self._height

    def perimeter(self) -> float:
        return 2 * (self._width + self._height)


class ShapeRenderer:
    def render(self, shape: Shape) -> None:
        # Knows nothing about Circle or Rectangle — only the Shape contract
        print(f"Rendering: {shape.describe()}")


renderer = ShapeRenderer()
renderer.render(Circle(5.0))
renderer.render(Rectangle(4.0, 6.0))

Java

Copy
public abstract class Shape {
    public abstract double area();
    public abstract double perimeter();

    public String describe() {
        return String.format("%s: area=%.2f, perimeter=%.2f",
            getClass().getSimpleName(), area(), perimeter());
    }
}

public class Circle extends Shape {
    private final double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double area() {
        return Math.PI * radius * radius;
    }

    @Override
    public double perimeter() {
        return 2 * Math.PI * radius;
    }
}

public class Rectangle extends Shape {
    private final double width;
    private final double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public double area() {
        return width * height;
    }

    @Override
    public double perimeter() {
        return 2 * (width + height);
    }
}

public class ShapeRenderer {
    public void render(Shape shape) {
        // Depends only on Shape — not Circle or Rectangle
        System.out.println("Rendering: " + shape.describe());
    }
}

3. Variants & Comparisons

Flavors of Abstraction

Language Constructs

• Python: abc.ABC + @abstractmethod for nominal abstraction; typing.Protocol for structural abstraction; bare duck typing for informal contracts.
• Java: abstract class when shared state/behavior is needed; interface (especially with Java 8+ default methods) for pure contracts. Key distinction: interfaces cannot hold instance variables or constructors.

4. When to Use It (and When NOT To)

Use abstraction when:

• Multiple concrete types share a common behavioral contract (shapes, payment methods, serializers).
• You need to swap implementations without changing callers (e.g., swap FileLogger for DatabaseLogger).
• You're writing a library or framework where callers provide their own implementations.
• You want testability — inject a mock/stub that implements the same abstract type.

Anti-patterns:

• Abstraction for one implementation: If there is exactly one class and no realistic second, the abstract layer is pure overhead. Add it when a second implementation appears.
• Leaky abstraction: The abstract interface exposes implementation-specific details (e.g., a Shape that has getSvgPath() — that's PDF vs SVG concern bleeding into the contract).
• God abstraction: A single abstract class that all domain objects extend to "share everything" — it becomes a dumping ground, violating SRP.

Decision triggers:

• "I have 3+ implementations of the same behavior" → define an abstraction.
• "I need to inject a test double for this dependency" → extract an abstraction.
• "The caller shouldn't care which concrete class it's working with" → program to an abstraction.
• "I only have one implementation today but the spec says more are coming" → define the abstraction now.

5. Real-World Usage

1. java.io.InputStream (Java standard library) InputStream is an abstract class. Concrete subclasses — FileInputStream, ByteArrayInputStream, BufferedInputStream — each override read() with storage-specific logic. Every Java API that reads bytes accepts InputStream, so callers are completely decoupled from the data source. Switching from file to in-memory buffer requires zero changes in the caller.

2. collections.abc (Python standard library) Python's collections.abc module defines abstract base classes like Iterable, Sequence, and Mapping. Built-in types (list, tuple, dict) implement these contracts. Any code that accepts Iterable works with lists, generators, sets, and custom containers without modification. This is abstraction enabling the for loop to work uniformly across all sequence types.

3. Sorting / comparison APIs Java's Comparator<T> interface and Python's key= callable parameter are both abstractions over comparison logic. Collections.sort(list, comparator) and sorted(items, key=fn) don't know what ordering strategy they're applying — they call the abstraction. Custom sort orders (by price, by name, by distance) are plugged in without touching the sort algorithm.

6. Interview Cheat Sheet

Key sentences to say

1. "Abstraction separates what an object does from how it does it — callers depend on the contract, not the implementation."
2. "In Java, I use an abstract class when related types need to share state or partial implementation; I use an interface when I want a pure behavioral contract that unrelated types can fulfill."
3. "Abstraction is what makes dependency injection and unit testing practical — you can swap a real implementation for a test double because they share the same abstract type."
4. "The rule I follow: program to the most abstract type that satisfies the caller's needs — don't expose concrete classes where an interface will do."
5. "Python's duck typing achieves abstraction implicitly — if it has the method, it satisfies the contract — but typing.Protocol gives you that with static type-checking."

Common follow-up questions

Q: What's the difference between abstraction and encapsulation? A: Encapsulation hides internal state behind methods to protect invariants. Abstraction hides implementation details behind an interface to decouple callers from specifics. Encapsulation is about data protection; abstraction is about reducing coupling.

Q: When would you choose an abstract class over an interface in Java? A: When the subtypes share concrete behavior or state. An abstract class can have fields and non-abstract methods — so if Animal needs a shared name field and a concrete sleep() method, an abstract class is appropriate. If I'm just defining a contract that unrelated types can fulfill (e.g., Comparable, Serializable), an interface is the right choice.

Q: Can you over-abstract? A: Yes. Premature abstraction creates indirection with no benefit — the YAGNI violation. The cost is indirection (harder to navigate, harder to understand). Add an abstraction when you have two implementations or a concrete need to swap, not speculatively.

Connections to other concepts

• Polymorphism depends on abstraction — you can only treat objects uniformly through a shared abstract type.
• Dependency Inversion Principle (DIP) formalizes abstraction as a rule: high-level modules must depend on abstractions, not concrete classes.
• Strategy pattern is abstraction applied to algorithms — the strategy interface is the abstraction; concrete strategies are the implementations.
• Factory pattern returns an abstract type, hiding which concrete class is instantiated.