Python OOP — Abstraction with ABC

The Story That Explains Abstraction

What Abstraction Really Means — Interface vs Implementation

Every abstraction has two sides. The interface is the promise: "if you're a Shape, you must be able to tell me your area." The implementation is how each concrete class fulfils that promise — a circle uses π·r², a rectangle uses w × h.

Why It Matters

Without abstraction, callers have to know which specific class they're dealing with. With abstraction, callers depend on the interface only — every new implementation slots in without a single line of caller code changing.

# Without abstraction — the caller must handle every payment type explicitly
def process(payment_type, data, amount):
    if payment_type == "credit":
        # Do card-specific stuff
        ...
    elif payment_type == "upi":
        # Do UPI-specific stuff
        ...
    elif payment_type == "crypto":
        # Do crypto-specific stuff
        ...
    # Adding a new payment method → edit this function → break existing callers

# WITH abstraction — the caller just talks to the interface
def process(payment: PaymentMethod, amount):
    payment.authenticate()
    payment.charge(amount)
    # A new payment method? Just implement PaymentMethod. No changes here.

Introducing ABC and @abstractmethod

Python's abc module ("Abstract Base Classes") gives you two things: ABC, a base class to inherit from, and @abstractmethod, a decorator that marks a method as must be overridden.

from abc import ABC, abstractmethod

class Shape(ABC):                     # inherit from ABC → this class is abstract
    # ── Abstract methods: no body needed, just a signature ──
    @abstractmethod
    def area(self):
        pass

    @abstractmethod
    def perimeter(self):
        pass


# Try to instantiate the abstract class directly → error
try:
    s = Shape()
except TypeError as e:
    print("Blocked:", e)
# Blocked: Can't instantiate abstract class Shape with abstract methods area, perimeter

Animated Diagram — The Contract and Its Implementations

Watch how one abstract Shape contract sits at the top, declaring area() and perimeter() as promises. Three concrete classes below — Circle, Rectangle, Triangle — each fulfil the promise in their own way. The interface is uniform; the implementations differ.

Abstract Classes Cannot Be Instantiated

This is the guarantee that makes abstract classes useful. Python refuses to create an instance of an abstract class until every abstract method has a concrete implementation. Try, and you get a TypeError at construction time — before any of your code can run.

from abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self):
        pass

    @abstractmethod
    def perimeter(self):
        pass


# ── Attempt 1: instantiate the abstract class directly ─────
try:
    s = Shape()
except TypeError as e:
    print("Blocked:", e)


# ── Attempt 2: subclass but forget one abstract method ─────
class HalfCircle(Shape):
    def area(self):
        return 42
    # perimeter() is still abstract — HalfCircle is still abstract too

try:
    h = HalfCircle()
except TypeError as e:
    print("Blocked:", e)


# ── Attempt 3: fully concrete — works ──────────────────────
class Square(Shape):
    def __init__(self, side):
        self.side = side
    def area(self):
        return self.side ** 2
    def perimeter(self):
        return 4 * self.side

sq = Square(5)                    # works — every abstract method is implemented
print(sq.area(), sq.perimeter())     # 25 20

Animated Diagram — Instantiation Attempts

Three creation attempts, three different outcomes. The abstract class itself is blocked. A half-implemented subclass is blocked. Only the fully-concrete subclass survives.

Abstract + Concrete Methods Together

An abstract class isn't only abstract methods. It can also contain fully implemented methods that every subclass inherits for free. That's how you share common behaviour while still enforcing the contract.

from abc import ABC, abstractmethod

class PaymentMethod(ABC):
    def __init__(self, holder):
        self.holder = holder                # concrete — shared setup

    # ── ABSTRACT — every subclass must implement ──
    @abstractmethod
    def authenticate(self):
        pass

    @abstractmethod
    def charge(self, amount):
        pass

    # ── CONCRETE — shared, but subclasses can still override ──
    def log_transaction(self, action, amount):
        print(f"  [log] {self.holder}: {action} of ${amount}")


class CreditCard(PaymentMethod):
    def __init__(self, holder, number):
        super().__init__(holder)          # reuse the base setup
        self.number = number

    def authenticate(self):
        print(f"Verifying card ****{self.number[-4:]}")
        return True

    def charge(self, amount):
        print(f"Charging ${amount} to card")
        self.log_transaction("charge", amount)   # inherited from base — no duplication

Animated Diagram — Polymorphism Through Abstraction

This is where abstraction pays off. A single function process(payment, amount) accepts any object that satisfies the PaymentMethod contract. Three concrete objects flow through it. Each one dispatches to its own charge() implementation — same interface, different behaviour, zero if/else.

Practical Example 1 — Payment Gateway With Multiple Methods

from abc import ABC, abstractmethod


class PaymentMethod(ABC):
    """Abstract base for every payment method."""

    def __init__(self, holder):
        self.holder = holder

    # ══ ABSTRACT — every payment method must implement ═══════
    @abstractmethod
    def authenticate(self) -> bool:
        """Verify the payer's identity."""
        ...

    @abstractmethod
    def charge(self, amount) -> None:
        """Deduct the amount from the payer."""
        ...

    @abstractmethod
    def refund(self, amount) -> None:
        """Return the amount to the payer."""
        ...

    # ══ CONCRETE — inherited by every payment method ═════════
    def log(self, action, amount):
        print(f"  [log] {self.holder}: {action} of {amount}")


class CreditCard(PaymentMethod):
    def __init__(self, holder, card_number):
        super().__init__(holder)
        self.card_number = card_number

    def authenticate(self):
        print(f"Verifying card ****{self.card_number[-4:]}")
        return True

    def charge(self, amount):
        print(f"Card charged ${amount}")
        self.log("card charge", amount)

    def refund(self, amount):
        print(f"Card refunded ${amount}")
        self.log("card refund", amount)


class UPIPayment(PaymentMethod):
    def __init__(self, holder, upi_id):
        super().__init__(holder)
        self.upi_id = upi_id

    def authenticate(self):
        print(f"UPI PIN check for {self.upi_id}")
        return True

    def charge(self, amount):
        print(f"Debiting ₹{amount} via UPI")
        self.log("UPI charge", amount)

    def refund(self, amount):
        print(f"Refunding ₹{amount} to UPI")
        self.log("UPI refund", amount)


class CryptoWallet(PaymentMethod):
    def __init__(self, holder, wallet_address):
        super().__init__(holder)
        self.wallet_address = wallet_address

    def authenticate(self):
        print("Verifying wallet signature")
        return True

    def charge(self, amount):
        print(f"Broadcasting {amount} to blockchain")
        self.log("crypto charge", amount)

    def refund(self, amount):
        print(f"Broadcasting refund of {amount}")
        self.log("crypto refund", amount)


# ══ Generic processor — does NOT know which method it holds ══
def process_purchase(payment: PaymentMethod, amount):
    print(f"\n▶ Processing for {payment.holder}:")
    if payment.authenticate():
        payment.charge(amount)


# One list of different concrete types, one uniform loop
payments = [
    CreditCard("Alice",   "4111111111113456"),
    UPIPayment("Bob",     "bob@upi"),
    CryptoWallet("Chandra", "0xabc123"),
]

for p in payments:
    process_purchase(p, 500)


# Trying to instantiate the abstract base is blocked
try:
    PaymentMethod("Anyone")
except TypeError as e:
    print("\nBlocked:", e)

Practical Example 2 — Shape Hierarchy

from abc import ABC, abstractmethod
import math


class Shape(ABC):
    @abstractmethod
    def area(self):
        ...

    @abstractmethod
    def perimeter(self):
        ...

    # Concrete — shared by every shape
    def describe(self):
        name = type(self).__name__
        print(f"{name:10s}  area={self.area():7.2f}  perimeter={self.perimeter():7.2f}")


class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius
    def area(self):
        return math.pi * self.radius ** 2
    def perimeter(self):
        return 2 * math.pi * self.radius


class Rectangle(Shape):
    def __init__(self, w, h):
        self.w, self.h = w, h
    def area(self):
        return self.w * self.h
    def perimeter(self):
        return 2 * (self.w + self.h)


class Triangle(Shape):
    def __init__(self, a, b, c):
        self.a, self.b, self.c = a, b, c
    def area(self):
        s = (self.a + self.b + self.c) / 2
        return math.sqrt(s * (s - self.a) * (s - self.b) * (s - self.c))
    def perimeter(self):
        return self.a + self.b + self.c


shapes: list[Shape] = [
    Circle(5),
    Rectangle(4, 6),
    Triangle(3, 4, 5),
]

for s in shapes:
    s.describe()   # inherited concrete method, uses each shape's own area/perimeter

Abstraction vs Encapsulation — Two Different Ideas

Beginners often confuse these two. They're both about "hiding," but they hide different things.

Common Mistakes (and Fixes)

Quick Reference

Golden Rules