Python OOP — Abstraction with ABC

The Story That Explains Abstraction ☕Abstraction समझाने वाली कहानी ☕一个讲清抽象（Abstraction）的故事 ☕

Interface vs Implementation 🎛️Interface बनाम Implementation 🎛️接口 vs 实现 🎛️

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

हर abstraction के दो पहलू होते हैं। Interface वादा है: "अगर तुम Shape हो, तो तुम्हें अपना area बताना ही होगा।" Implementation यह है कि हर concrete class वह वादा कैसे निभाती है — circle π·r² लेता है, rectangle w × h।

每个抽象都有两面。接口 是承诺："如果你是一个 Shape，你就必须能告诉我你的面积。"实现 是每个具体类如何兑现这个承诺 — 圆用 π·r²，矩形用 w × h。

Why It Mattersयह क्यों ज़रूरी है为什么这很重要

Without abstraction, callers must know which exact class they are dealing with. With abstraction, callers depend only on the interface — and a new implementation slots in without changing a single line of caller code. This is a short sketch to compare the two styles (it is not meant to be run):

Abstraction के बिना callers को पता होना चाहिए कि वे किस class से बात कर रहे हैं। Abstraction के साथ callers सिर्फ़ interface पर निर्भर होते हैं — और नया implementation caller के code की एक भी line बदले बिना जुड़ जाता है। दोनों तरीक़ों की तुलना के लिए यह छोटा sketch है (इसे चलाने के लिए नहीं लिखा गया):

没有抽象时，调用方必须知道自己面对的是哪个具体类。有了抽象，调用方只依赖接口 — 新的实现可以直接接入，调用方代码一行都不用改。下面是比较两种写法的简短示意（不用于运行）：

# Without abstraction - the caller must handle every payment type itself
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
        ...
    # A new payment method -> edit this function -> risk breaking 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.

Meet ABC and @abstractmethod 🧩ABC और @abstractmethod से मिलिए 🧩认识 ABC 和 @abstractmethod 🧩

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

Python का abc module ("Abstract Base Classes") दो औज़ार देता है: ABC, जिससे inherit करते हैं, और @abstractmethod, एक decorator जो method को override करना ज़रूरी बताता है।

Python 的 abc 模块（"抽象基类"）提供两样工具：ABC，一个用来继承的基类；以及 @abstractmethod，一个把方法标记为 必须重写 的装饰器。

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)

The Contract and Its Implementations 📜Contract और उसके Implementations 📜契约与它的实现 📜

One abstract Shape contract sits at the top. It declares area() and perimeter() as promises. Three concrete classes below — Circle, Rectangle, Triangle — each keep the promise in their own way. The interface is the same; the implementations differ.

ऊपर एक abstract Shape contract है। यह area() और perimeter() को वादों के रूप में घोषित करता है। नीचे तीन concrete classes — Circle, Rectangle, Triangle — अपने-अपने तरीक़े से वादा निभाती हैं। Interface एक जैसा है; implementations अलग।

顶部是一个抽象的 Shape 契约，它把 area() 和 perimeter() 声明为承诺。下面三个具体类 — Circle、Rectangle、Triangle — 各自用自己的方式兑现承诺。接口相同，实现不同。

Abstract Classes Cannot Be Instantiated 🚫Abstract Class का Object नहीं बनता 🚫抽象类不能被实例化 🚫

This guarantee is what makes abstract classes useful. Python refuses to create an object of an abstract class until every abstract method has a real implementation. If you try, you get a TypeError at creation time — before any of your methods can run.

यही guarantee abstract classes को काम का बनाती है। जब तक हर abstract method का असली implementation न हो, Python abstract class का object बनाने से मना कर देता है। कोशिश करें तो object बनते समय ही TypeError मिलता है — आपका कोई method चलने से पहले।

这个保证正是抽象类有用的原因。在每个抽象方法都有真正的实现之前，Python 拒绝 创建抽象类的对象。如果你尝试，在创建时就会得到 TypeError — 在你的任何方法运行之前。

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

🧪 Simulator: ABC Gate Lab🧪 Simulator: ABC Gate Lab🧪 模拟器：ABC 关卡实验室

Switch the pieces on and off. Remove (ABC), remove an @abstractmethod, forget a method in Square — then watch the gate. The code and output are checked against real Python for all 64 combinations.

हिस्सों को on/off कीजिए। (ABC) हटाइए, कोई @abstractmethod हटाइए, Square में कोई method भूल जाइए — फिर gate देखिए। Code और output सभी 64 combinations के लिए असली Python से जाँचे गए हैं।

把各个部分打开或关闭。去掉 (ABC)、去掉某个 @abstractmethod、在 Square 里漏掉一个方法 — 然后看关卡的反应。全部 64 种组合的代码和输出都已与真实 Python 对照。

Abstract and Concrete Methods Together 🤝Abstract और Concrete Methods साथ-साथ 🤝抽象方法与具体方法并存 🤝

An abstract class is not only abstract methods. It can also hold fully written methods that every subclass inherits for free. This is how you share common behaviour and still enforce the contract.

Abstract class में सिर्फ़ abstract methods नहीं होते। उसमें पूरे लिखे हुए methods भी हो सकते हैं, जो हर subclass को मुफ़्त में inherit होते हैं। इसी तरह आप साझा व्यवहार बाँटते हैं और contract भी लागू रखते हैं।

抽象类里不 只 有抽象方法。它也可以包含完整写好的方法，每个子类都能免费继承。这样你既能共享通用行为，又能强制执行契约。

Below, PaymentMethod has a concrete __init__ and log_transaction, plus two abstract methods. The last three lines (added so you can see real output) use the CreditCard subclass.

नीचे PaymentMethod में concrete __init__ और log_transaction हैं, साथ में दो abstract methods। आख़िरी तीन lines (ताकि आप असली output देख सकें) CreditCard subclass इस्तेमाल करती हैं।

下面的 PaymentMethod 有具体的 __init__ 和 log_transaction，外加两个抽象方法。最后三行（为了让你看到真实输出而添加）使用了 CreditCard 子类。

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


card = CreditCard("Alice", "4111111111113456")
if card.authenticate():
    card.charge(500)

🧠 Simulator: Abstract or Concrete?🧠 Simulator: Abstract या Concrete?🧠 模拟器：抽象还是具体？

Eight methods from this tutorial. For each one, ask: "Would every subclass write this exactly the same way?" Yes → concrete. No → abstract.

इस tutorial के आठ methods। हर एक के लिए पूछिए: "क्या हर subclass इसे बिल्कुल एक जैसा लिखेगी?" हाँ → concrete। नहीं → abstract।

本教程中的八个方法。对每一个问一句："每个子类都会用完全一样的方式写它吗？" 是 → 具体。否 → 抽象。

Polymorphism Through Abstraction 🔀Abstraction के ज़रिए Polymorphism 🔀通过抽象实现多态 🔀

This is where abstraction pays off. One function, process(payment, amount), accepts any object that follows the PaymentMethod contract. Three different objects go through it. Each one runs its own charge() — same interface, different behaviour, no if/else.

यहीं abstraction का फ़ायदा मिलता है। एक function, process(payment, amount), ऐसा कोई भी object लेता है जो PaymentMethod contract मानता हो। तीन अलग objects इससे गुज़रते हैं। हर एक अपना charge() चलाता है — वही interface, अलग व्यवहार, कोई if/else नहीं।

这正是抽象的回报。一个函数 process(payment, amount) 接受 任何 遵守 PaymentMethod 契约的对象。三个不同的对象经过它，每个都运行 自己的 charge() — 接口相同，行为不同，没有 if/else。

Practical Example 1 — Payment Gateway 💳Practical Example 1 — Payment Gateway 💳实战示例 1 — 支付网关 💳

Three payment methods follow one abstract contract. The processor function does not know — or care — which one it holds.

तीन payment methods एक ही abstract contract मानते हैं। Processor function को पता नहीं — न परवाह — कि उसके पास कौन-सा है।

三种支付方式遵守同一份抽象契约。处理函数不知道 — 也不关心 — 自己拿到的是哪一种。

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)

💳 Simulator: Payment Router💳 Simulator: Payment Router💳 模拟器：支付路由器

Pick an object, an action and an amount. Watch which methods run, in order: the subclass's own versions, and the shared log() from the abstract base. ApplePay is a brand-new subclass — process_purchase was not touched.

Object, action और amount चुनिए। देखिए कौन-से methods किस क्रम में चलते हैं: subclass के अपने versions, और abstract base का साझा log()। ApplePay बिल्कुल नई subclass है — process_purchase को छुआ तक नहीं गया।

选择一个对象、一个操作和一个金额。观察哪些方法按什么顺序运行：子类自己的版本，以及抽象基类中共享的 log()。ApplePay 是全新的子类 — process_purchase 一点没改。

Practical Example 2 — Shape Hierarchy 📐Practical Example 2 — Shape Hierarchy 📐实战示例 2 — 图形层次结构 📐

Here the abstract Shape also has a concrete describe(). It is written once, in the base class — yet it prints the right numbers for every shape, because it calls self.area() and self.perimeter(), and those run each subclass's own version.

यहाँ abstract Shape में एक concrete describe() भी है। यह base class में सिर्फ़ एक बार लिखा है — फिर भी हर shape के सही नंबर छापता है, क्योंकि यह self.area() और self.perimeter() बुलाता है, और वे हर subclass का अपना version चलाते हैं।

这里的抽象类 Shape 还有一个具体方法 describe()。它只在基类里写了一次 — 却能为每种图形打印正确的数字，因为它调用 self.area() 和 self.perimeter()，而这两个方法运行的是各个子类自己的版本。

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

👣 Simulator: describe() Step by Step👣 Simulator: describe() क़दम-दर-क़दम👣 模拟器：describe() 逐步演示

A shorter version of the code, recorded with sys.settrace. Watch the call stack: Shape.describe() (the shared concrete method) calls down into Circle.area() or Rectangle.area(). The abstract Shape.area() never runs.

Code का छोटा version, sys.settrace से रिकॉर्ड किया हुआ। Call stack देखिए: Shape.describe() (साझा concrete method) नीचे Circle.area() या Rectangle.area() को बुलाता है। Abstract Shape.area() कभी नहीं चलता।

这是代码的精简版，用 sys.settrace 录制。观察调用栈：Shape.describe()（共享的具体方法）向下调用 Circle.area() 或 Rectangle.area()。抽象的 Shape.area() 从未运行。

📐 Simulator: Shape Studio📐 Simulator: Shape Studio📐 模拟器：图形工作室

Change the sizes and watch the inherited describe() line update. Try a triangle whose sides cannot meet, such as 2, 3, 9 — the subclass's area() fails, not the contract. Checked against Python on 320 shapes.

Sizes बदलिए और inherited describe() की line बदलते देखिए। ऐसा triangle आज़माइए जिसकी भुजाएँ मिल न सकें, जैसे 2, 3, 9 — subclass का area() fail होता है, contract नहीं। 320 shapes पर Python से जाँचा गया।

改变尺寸，看继承来的 describe() 输出如何变化。试试三边无法围成三角形的情况，比如 2、3、9 — 出错的是子类的 area()，而不是契约。已在 320 个图形上与 Python 对照。

Abstraction vs Encapsulation ⚖️Abstraction बनाम Encapsulation ⚖️抽象 vs 封装 ⚖️

Beginners often mix these two up. Both are about "hiding", but they hide different things.

Beginners अक्सर इन दोनों को मिला देते हैं। दोनों "छिपाने" के बारे में हैं, पर अलग-अलग चीज़ें छिपाते हैं।

初学者经常把这两个概念搞混。两者都与"隐藏"有关，但隐藏的东西不同。

Common Mistakes (and Fixes) 🩹आम ग़लतियाँ (और उनके हल) 🩹常见错误（及修正）🩹

🩺 Simulator: Bug Doctor🩺 Simulator: Bug Doctor🩺 模拟器：Bug 医生

Five of these mistakes, run for real. Buggy code on the left, fixed code on the right, changed lines marked. Notice that two bugs give no error at all — only a quiet None.

इनमें से पाँच ग़लतियाँ, असली run में। बाईं ओर buggy code, दाईं ओर ठीक किया हुआ, बदली lines चिह्नित। ध्यान दें: दो bugs में कोई error नहीं आता — बस चुपचाप None।

其中五个错误的真实运行。左边是有 bug 的代码，右边是修正后的代码，改动的行已标出。注意有两个 bug 完全不报错 — 只是悄悄返回 None。

Quick Reference 📋Quick Reference 📋速查表 📋

The __abstractmethods__ row in action (sorted, because a frozenset has no fixed order):

__abstractmethods__ वाली row असल में (sorted, क्योंकि frozenset का कोई तय क्रम नहीं होता):

__abstractmethods__ 这一行的实际效果（用 sorted 排序，因为 frozenset 没有固定顺序）：

from abc import ABC, abstractmethod

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

class HalfCircle(Shape):
    def area(self):
        return 42

class Square(Shape):
    def area(self):
        return 25
    def perimeter(self):
        return 20

print(sorted(Shape.__abstractmethods__))
print(sorted(HalfCircle.__abstractmethods__))
print(Square.__abstractmethods__)

Golden Rules and Quiz 🏆सुनहरे नियम और Quiz 🏆黄金法则与小测验 🏆

Quick Quiz — 8 Questionsछोटा Quiz — 8 सवाल小测验 — 8 道题