What Is Abstraction in Programming?

When you write print("hi"), you do not think about how those letters reach the screen. Under that one line, Python turns the text into bytes and asks the operating system to write them, the operating system hands them to your terminal, and the terminal draws each letter as pixels using a font. Each layer offers the one above it a simple promise and hides how it keeps that promise. That hiding is abstraction, and every program sits on top of many such layers.

Levels of abstraction

Each level is built from the one below and can be understood without it. You can write working Python without knowing what a disk block is, and the operating system can store a file without knowing it holds Python code.

How abstraction works in code

Programmers build their own layers in two main ways.

Procedural abstraction is a function. Its name, parameters and return value are the interface; the body is the hidden detail. Once average(scores) exists, the rest of the program uses it without reading how it adds and divides.

Data abstraction defines a type by what you can do with it, not by how it stores things. A queue is "add at the back, take from the front". How the items sit in memory is a private decision:

from collections import deque

class Queue:
    """First in, first out. Callers only see add() and next()."""
    def __init__(self):
        self._items = deque()     # swap this for a list and callers never notice
    def add(self, item):
        self._items.append(item)
    def next(self):
        return self._items.popleft()
    def __len__(self):
        return len(self._items)

orders = Queue()
for dish in ["soup", "pasta", "cake"]:
    orders.add(dish)
while len(orders):
    print("serving", orders.next())

serving soup
serving pasta
serving cake

The code at the bottom knows nothing about deque. If you replace it with a plain list and pop(0), the output is identical, only slower for long queues, because removing the first item of a list moves every other item. The interface stayed the same, so nothing outside the class had to change.

Abstract classes and interfaces

In object-oriented programming, abstraction usually means stating what a family of classes must do while leaving how to each class. In Python, the abc module marks a method as abstract; a class with an unimplemented abstract method cannot be instantiated:

from abc import ABC, abstractmethod

class Notifier(ABC):
    @abstractmethod
    def send(self, to, text):
        """Every notifier must say how it sends a message."""

class Email(Notifier):
    def send(self, to, text):
        print(f"email to {to}: {text}")

class SMS(Notifier):
    def send(self, to, text):
        print(f"sms to {to}: {text}")

def remind(notifier, user):
    notifier.send(user, "Your package arrives today")

remind(Email(), "ana@example.com")
remind(SMS(), "+15550100")
try:
    Notifier()
except TypeError:
    print("Notifier is abstract: create an Email or an SMS instead")

email to ana@example.com: Your package arrives today
sms to +15550100: Your package arrives today
Notifier is abstract: create an Email or an SMS instead

remind() depends only on the abstraction: anything with a send method. Adding push notifications means writing one new class, and remind() stays untouched. That last step, one call running different code for different classes, is polymorphism: abstraction defines the shared interface, polymorphism makes it work.

Java has the same tools as keywords:

interface Notifier {
    void send(String to, String text);
}

class Email implements Notifier {
    public void send(String to, String text) { /* talk to the mail server */ }
}

Writing new Notifier() is a compile error, because an interface has no implementation to run. The docs explain abstract classes and interfaces in Java in detail.

Abstraction vs encapsulation

The two ideas appear together so often that they are easy to mix up.

Abstraction decides which operations to show; encapsulation makes sure the rest stays hidden. The Queue above does both: add and next are the abstraction, and the underscore on _items is the encapsulation.

Leaky abstractions and other mistakes

Joel Spolsky named the law of leaky abstractions in 2002: every non-trivial abstraction lets some of the hidden detail through. Floating-point numbers are the classic leak. They look like ordinary decimals, until the binary storage underneath shows through:

print(0.1 + 0.2)
print(0.1 + 0.2 == 0.3)

0.30000000000000004
False

Neither 0.1 nor 0.2 can be stored exactly in binary bits, so the sum is slightly off. You can use floats for years without thinking about this, but not forever, which is why it helps to know one layer below the one you work in.

Two more mistakes are common:

• Abstracting too early. A class hierarchy built for cases that never arrive is extra code to read and change. Sandi Metz put it as "duplication is far cheaper than the wrong abstraction".
• Confusing abstraction with the abstract keyword. Abstract classes are one tool. Every well-named function is an abstraction too.

Where to go next

Read encapsulation and polymorphism to complete the object-oriented picture. The operating system page shows the biggest abstraction your programs rely on. To practice, the Python course builds classes and functions from the start, and the Java course covers abstract classes and interfaces.