What is abstraction in OOP?

Question

Accepted Answer

**Abstraction** means exposing *what* an object does while hiding *how* it does it. You interact with a simple, stable interface and ignore the messy implementation behind it.

## What vs. how

```python
from abc import ABC, abstractmethod

class PaymentGateway(ABC):          # the abstraction: "what"
    @abstractmethod
    def charge(self, amount): ...    # callers only need this contract

class StripeGateway(PaymentGateway): # one "how"
    def charge(self, amount):
        # talk to Stripe's API, handle tokens, retries...
        return f"charged {amount} via Stripe"

class PayPalGateway(PaymentGateway): # another "how"
    def charge(self, amount):
        return f"charged {amount} via PayPal"

def checkout(gateway: PaymentGateway, amount):
    return gateway.charge(amount)    # depends only on the abstraction
```

`checkout` never knows whether it's Stripe or PayPal — it depends on the *idea* of charging, not the details.

## Abstraction vs. encapsulation

They're related but distinct: **encapsulation** hides state to protect it; **abstraction** hides complexity to simplify the interface. Encapsulation is about *protection*; abstraction is about *what to show*.

## Pitfall

Leaky abstractions (where implementation details bleed through) and premature abstractions (built before you understand the problem) both hurt. Abstract what genuinely varies.

## Why it matters

Abstraction is how you tame complexity: callers reason about a small interface instead of an entire subsystem.

It enables swapping implementations — adding a new payment provider touches one class, not every caller — which is the foundation of flexible, testable design.