Abstraction

Abstraction shows callers what a component does and hides how. Choosing what to show is the central design decision in every class, interface and service boundary.

Overview

Abstraction is the act of naming a thing by what it does and leaving out how it does it. A caller of storage.save(key, bytes) does not know or care whether the bytes went to a local disk, S3 or memory. That ignorance is the point: the caller's code stays simple, the implementation can change, and two people can work on the two sides without talking every hour.

Every level of a program is an abstraction over the one below it. A function abstracts a sequence of statements. A class abstracts data plus the operations on it. An interface or abstract class abstracts a family of classes. A service abstracts a whole process behind an API. Interviewers are not testing whether you know the word; they are testing whether you choose the right things to hide, and whether you notice when a detail is leaking through.

Show what, hide how

Function — total_price(cart) — the loop, the rounding, the tax table
Class — BankAccount.withdraw(cents) — the balance field, the overdraft rule, the audit log
Interface or abstract class — Storage.save(key, data) — S3 versus disk, retries, credentials
Module or service — POST /payments — the whole payment pipeline, its database, its vendors

The two tools in the language

An abstract class and an interface both let you write code against a type that has no complete implementation. They differ in whether the abstraction carries shared code and state.

Can be instantiated — no — no
Holds fields — yes, any visibility — no; constants only
Holds shared code — yes: concrete methods that call abstract ones — Java default methods only, with no fields to use
A class can have — one — many
Java — abstract class, abstract methods — interface
Python — abc.ABC with @abstractmethod; instantiation fails until every abstract method is overridden — the same ABC with no concrete methods, or a typing.Protocol

The abstract class shines when the algorithm is fixed and a few steps vary. The base holds the algorithm and calls abstract steps; subclasses fill in only those steps. That shape is the Template Method pattern.

Abstraction is not encapsulation

The two words travel together and get confused. Abstraction is about the outside: what the caller sees. Encapsulation is about the inside: keeping state and the code that guards it in one place, out of reach. A class can have one without the other.

Question it answers — what can I ask this to do? — who is allowed to change this state?
Tool — interfaces, abstract classes, small public APIs — private fields, methods that enforce invariants
Failure — callers must know internals to use it (a leak) — any code can put the object into a bad state
Example — List says add, remove, get — ArrayList keeps its array and size private

Every abstraction leaks somewhere

Joel Spolsky's 2002 essay stated it as a law: all non-trivial abstractions, to some degree, are leaky. His example is TCP, which promises reliable delivery on top of IP, which promises nothing; when the cable is cut, the abstraction cannot hide it. The design lesson is not to avoid abstraction but to decide, on purpose, which details are allowed through.

Remote calls look local — they can time out and be slow — make failure part of the contract: timeouts, retryable errors
A lazy-loading ORM — one loop becomes hundreds of queries — expose the loading choice, or measure and document it
A cache in front of a store — reads can be stale — say so in the interface name or docs
A virtual file system — some paths are slow or read-only — return capabilities, not silence

What you will be able to do

Describe a component by what it does, and list what it hides, in one breath.
Pick an abstract class or an interface for a reason, and write the Template Method shape when it fits.
Separate abstraction from encapsulation when asked, with an example of each.
Choose the level of an abstraction from who calls it, and defend the choice.
Name a leak in a design you are shown and say how the contract should absorb it.

Interview questions

How do abstract classes and interfaces implement abstraction?
What is the difference between abstraction and encapsulation?
How do you choose the right level of abstraction?
What is a leaky abstraction, and how do you design for it?
When is abstraction harmful?