{"title":"Abstract Classes","description":"","content":"Abstraction is the act of saying \"here is what every payment method must do\" without spelling out how any particular method does it. Python's `abc` module turns that idea into an enforceable contract: a base class can declare methods that subclasses are required to implement, and Python will refuse to instantiate the base class itself. This lesson covers what abstraction means in OOP, why duck typing alone leaves holes, and how `ABC` and `@abstractmethod` close them.\n\n---\n\n# What Abstraction Means in OOP\n\nAbstraction is one of the four pillars of object-oriented programming, alongside encapsulation, inheritance, and polymorphism. The everyday meaning is the one that matters: hide the messy details, expose a clean shape. When you say `processor.charge(99.99)`, you don't want to know whether the call talks to a credit card system or a PayPal account or a store credit balance. You want one method name, one set of arguments, one predictable return.\n\nThe class that defines the shape (`PaymentProcessor` with a `charge` method) is the abstraction. The classes that fill in the details (`CreditCardProcessor`, `PayPalProcessor`, `StoreCreditProcessor`) are the concrete implementations. Code that uses these processors doesn't care which one it has; it just calls `charge` and trusts the contract.\n\n\n```mermaid\nflowchart TD\n Abstract[\"PaymentProcessor
abstract
charge(), refund()\"]:::cyan\n CC[\"CreditCardProcessor
concrete\"]:::orange\n PP[\"PayPalProcessor
concrete\"]:::orange\n SC[\"StoreCreditProcessor
concrete\"]:::orange\n\n Abstract --> CC\n Abstract --> PP\n Abstract --> SC\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe cyan box is the abstract class. It declares the shape (which methods exist and what they look like) but doesn't implement them. The orange boxes are concrete subclasses that fill in the implementation. Code elsewhere in the program can hold a reference typed as `PaymentProcessor` and not care which orange box it actually got.\n\nThe benefit shows up the moment you add a fourth payment method. If every caller talks to `processor.charge(amount)`, adding a `BankTransferProcessor` is a matter of writing one class. No caller changes. That's the payoff abstraction is buying you.\n\n---\n\n# The Problem With Just Relying on Duck Typing\n\nPython has duck typing, and for small programs that's often enough. If something walks like a payment processor and quacks like a payment processor (it has a `charge` method that takes an amount), you can pass it where a payment processor is expected. No formal contract required.\n\n\n```python\nclass CreditCardProcessor:\n def charge(self, amount):\n print(f\"Charging ${amount:.2f} to credit card\")\n\nclass PayPalProcessor:\n def charge(self, amount):\n print(f\"Charging ${amount:.2f} via PayPal\")\n\ndef checkout(processor, amount):\n processor.charge(amount)\n\ncheckout(CreditCardProcessor(), 49.99)\ncheckout(PayPalProcessor(), 49.99)\n```\n\n\nThis works. Neither class inherits from anything special; `checkout` just trusts that whatever it received has a `charge` method. The trouble starts when someone writes a new processor and forgets one of the methods, or names it slightly wrong:\n\n\n```python\nclass StoreCreditProcessor:\n def charge_amount(self, amount):\n print(f\"Deducting ${amount:.2f} from store credit\")\n\ncheckout(StoreCreditProcessor(), 49.99)\n```\n\n\nThe bug only shows up when `checkout` actually runs, at the moment of the call. If `checkout` only runs in a rare branch (a refund flow, a promotional credit, a failed retry), the error can hide for weeks. Duck typing trusts the developer to remember the contract. The contract isn't written down anywhere, so it relies on convention and memory.\n\nThis is the gap `abc` fills. By declaring \"every `PaymentProcessor` must have a `charge` method\", Python can catch a missing method at class creation time, not at call time. The bug surfaces when you write the class, not when an unlucky customer hits checkout.\n\n---\n\n# `abc.ABC` and `@abstractmethod`\n\nThe `abc` module (short for \"abstract base classes\") lives in the standard library. To declare an abstract class, inherit from `abc.ABC` and decorate the methods you want subclasses to implement with `@abc.abstractmethod`:\n\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass PaymentProcessor(ABC):\n @abstractmethod\n def charge(self, amount):\n pass\n\n @abstractmethod\n def refund(self, amount):\n pass\n```\n\n\nTwo things are happening here. First, `PaymentProcessor` inherits from `ABC`, which marks the class as abstract. Second, `charge` and `refund` are decorated with `@abstractmethod`, which marks those specific methods as abstract. The body of each method is just `pass` because the base class isn't supposed to do the work; that's the subclass's job.\n\nA class becomes \"abstract\" the moment it has at least one method marked with `@abstractmethod`. Inheriting from `ABC` is what wires Python's metaclass machinery in so the abstractness is actually enforced. Skip the `ABC` part and the decorator becomes a polite suggestion with no teeth.\n\nYou can still write code inside an abstract method's body if you want. A common pattern is to put shared logic there and ask subclasses to call it through `super()`:\n\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass PaymentProcessor(ABC):\n @abstractmethod\n def charge(self, amount):\n print(f\"Logging charge attempt for ${amount:.2f}\")\n```\n\n\nThe `@abstractmethod` decorator says \"subclasses must override this\", it doesn't say \"the body has to be empty\". Most of the time the body is `pass` or a docstring, but `super().charge(amount)` from the subclass remains a valid way to reuse logic.\n\n---\n\n# Trying to Instantiate an Abstract Class Raises `TypeError`\n\nThe first thing `ABC` enforces is that you can't instantiate the abstract class directly. The whole point is that `PaymentProcessor` is a shape, not a usable object:\n\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass PaymentProcessor(ABC):\n @abstractmethod\n def charge(self, amount):\n pass\n\n @abstractmethod\n def refund(self, amount):\n pass\n\nprocessor = PaymentProcessor()\n```\n\n\nPython checks the abstract-method registry at the moment of construction and refuses. The error names the class and the methods that are still abstract. If you were hoping to use `PaymentProcessor` as a placeholder for \"I'll figure out the details later\", you can't; the class only becomes usable once a concrete subclass fills in every abstract method.\n\nThis guard is the main reason to bother with `abc` at all. Duck typing trusts you to never instantiate the base class; `abc` makes it a runtime error. Mistakes that would have silently produced a half-working object now fail loudly at the spot you tried to make one.\n\n---\n\n# Subclass Must Implement All Abstract Methods\n\nA subclass becomes concrete only when every abstract method from its parent has been overridden. Miss even one, and the subclass is still abstract and still can't be instantiated:\n\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass PaymentProcessor(ABC):\n @abstractmethod\n def charge(self, amount):\n pass\n\n @abstractmethod\n def refund(self, amount):\n pass\n\nclass CreditCardProcessor(PaymentProcessor):\n def charge(self, amount):\n print(f\"Charging ${amount:.2f} to credit card\")\n\nprocessor = CreditCardProcessor()\n```\n\n\n`CreditCardProcessor` implemented `charge` but forgot `refund`. Python knows because the abstract-method set propagates down the inheritance chain. Add the missing method and the class becomes instantiable:\n\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass PaymentProcessor(ABC):\n @abstractmethod\n def charge(self, amount):\n pass\n\n @abstractmethod\n def refund(self, amount):\n pass\n\nclass CreditCardProcessor(PaymentProcessor):\n def charge(self, amount):\n print(f\"Charging ${amount:.2f} to credit card\")\n\n def refund(self, amount):\n print(f\"Refunding ${amount:.2f} to credit card\")\n\nprocessor = CreditCardProcessor()\nprocessor.charge(49.99)\nprocessor.refund(10.00)\n```\n\n\nThe same rules apply to deeper hierarchies. If `CreditCardProcessor` itself only fills in `charge` and a further subclass `PremiumCardProcessor(CreditCardProcessor)` fills in `refund`, then `PremiumCardProcessor` is concrete and `CreditCardProcessor` is not. Abstractness is \"any unimplemented abstract method in the chain\", concrete is \"every abstract method has been overridden somewhere on the path from `object` down to this class\".\n\nThere's also no rule that says a concrete subclass has to mark anything as abstract itself. You can have a concrete subclass that adds new methods, new attributes, or stays a faithful implementation of the parent's shape. The only requirement is that no abstract method is left hanging.\n\n---\n\n# `@abstractmethod` Combined With `@property`\n\nAbstract methods cover behavior. Sometimes the contract is about state instead: every shippable item must expose a `weight` value, every discountable item must expose a `price`. Python lets you mark a `@property` as abstract by stacking the two decorators:\n\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass Shippable(ABC):\n @property\n @abstractmethod\n def weight(self):\n pass\n\n @property\n @abstractmethod\n def dimensions(self):\n pass\n\nclass Book(Shippable):\n def __init__(self, title, weight_kg, dims):\n self.title = title\n self._weight = weight_kg\n self._dims = dims\n\n @property\n def weight(self):\n return self._weight\n\n @property\n def dimensions(self):\n return self._dims\n\nitem = Book(\"Python in Practice\", 0.45, (20, 15, 3))\nprint(f\"{item.title} weighs {item.weight} kg\")\nprint(f\"Dimensions: {item.dimensions}\")\n```\n\n\nThe order of the decorators matters: `@property` goes on top, `@abstractmethod` goes underneath. Python reads decorators bottom-up, so `@abstractmethod` runs first and marks the function as abstract, then `@property` wraps it as a property descriptor. Reverse the order and you get a property whose getter happens to be abstract but isn't tracked correctly in the abstract-method set, which means the enforcement breaks.\n\nIf `Book` had forgotten to define `weight`, trying to instantiate it would fail with the same `TypeError` you saw for abstract methods. The check is uniform: any name left abstract anywhere on the inheritance path blocks construction.\n\nThe point here is that `@abstractmethod` composes with `@property` to express \"subclasses must expose this as a read-only attribute\".\n\n---\n\n# `ABCMeta` and Why Inheriting From `ABC` Matters\n\nUnder the hood, abstract classes use a special metaclass called `ABCMeta`. A metaclass is the class of a class, the thing that controls how a class is built. `ABCMeta` is what tracks the set of abstract methods and intercepts construction to raise `TypeError` when any of them are unimplemented.\n\nYou don't usually deal with `ABCMeta` directly because `ABC` is a tiny helper class defined in the `abc` module that does it for you:\n\n\n```python\nclass ABC(metaclass=ABCMeta):\n pass\n```\n\n\nInheriting from `ABC` is the modern, readable way to get the metaclass wired up. The older way, still legal Python, is to set the metaclass directly:\n\n\n```python\nfrom abc import ABCMeta, abstractmethod\n\nclass PaymentProcessor(metaclass=ABCMeta):\n @abstractmethod\n def charge(self, amount):\n pass\n```\n\n\nBoth styles produce an equivalent abstract class. `class Foo(ABC)` reads better and is the recommended form in any code written today. The `metaclass=ABCMeta` form is mostly useful when a class already needs a different base and you want to layer abstractness on top, or when you're working with code that predates `ABC` (added in Python 3.4).\n\nThe catch worth knowing: `@abstractmethod` only enforces anything when the class has `ABCMeta` somewhere in its metaclass chain. Decorate a method with `@abstractmethod` on a plain class that doesn't inherit from `ABC` and doesn't set `metaclass=ABCMeta`, and the decorator becomes a no-op. The class is freely instantiable and the abstract method is just a regular method with a confusing decorator on it:\n\n\n```python\nfrom abc import abstractmethod\n\nclass PaymentProcessor:\n @abstractmethod\n def charge(self, amount):\n pass\n\nprocessor = PaymentProcessor()\nprint(\"Created an 'abstract' class instance with no error\")\n```\n\n\nThe instantiation succeeds because `PaymentProcessor` doesn't use `ABCMeta`, and without `ABCMeta` there's nothing watching for unimplemented abstract methods. The decorator is still there as documentation, but it's not enforced. Always pair `@abstractmethod` with `ABC` or `ABCMeta`, or you've built a contract with no signatures on it.\n\n---\n\n# When to Use ABC vs `typing.Protocol`\n\nPython has two ways to describe \"an object that has these methods\". `abc.ABC` is one. The other is `typing.Protocol` (added in Python 3.8), and it's worth knowing the difference.\n\n`ABC` is a **nominal** contract: a class is a `PaymentProcessor` because it inherits from `PaymentProcessor`. Inheritance is explicit, instantiation is checked at runtime, and forgetting a method is a `TypeError` the moment you try to create an instance.\n\n`Protocol` is a **structural** contract: a class is a payment processor because it has the methods, regardless of what it inherits from. Static type checkers (like mypy or Pyright) verify the shape at type-check time. There's no runtime enforcement by default, and no inheritance required.\n\n\n| Aspect | `abc.ABC` | `typing.Protocol` |\n| --- | --- | --- |\n| Style | Nominal (explicit inheritance) | Structural (duck-typed) |\n| Enforced at | Runtime, on instantiation | Type-check time (mypy, Pyright) |\n| Subclass relationship | Required (`class C(P)`) | Not required |\n| Caught error | `TypeError` for missing methods | Type-check warning |\n| Best for | Library authors who want to lock the contract | API surfaces that should accept anything matching the shape |\n\n\nThe short rule: reach for `ABC` when you control the subclasses and want runtime guarantees that every implementation is complete. Reach for `Protocol` when you want to type-check that some object out there satisfies an interface without forcing it to inherit from anything. The two aren't mutually exclusive, plenty of codebases use both, and the structural-vs-nominal distinction is the lever that decides which fits.\n\nFor this lesson, the takeaway is that `ABC` isn't the only option and the two solve slightly different problems.\n\n---\n\n# A Worked E-Commerce Example: Abstract `PaymentProcessor`\n\nPulling the pieces together, here's a small payment system using `ABC`:\n\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass PaymentProcessor(ABC):\n \"\"\"Contract for anything that can charge and refund money.\"\"\"\n\n @abstractmethod\n def charge(self, amount):\n pass\n\n @abstractmethod\n def refund(self, amount):\n pass\n\n def describe(self):\n return f\"Payment processor: {type(self).__name__}\"\n\nclass CreditCardProcessor(PaymentProcessor):\n def __init__(self, card_last_four):\n self.card_last_four = card_last_four\n\n def charge(self, amount):\n print(f\"Charging ${amount:.2f} to card ending {self.card_last_four}\")\n\n def refund(self, amount):\n print(f\"Refunding ${amount:.2f} to card ending {self.card_last_four}\")\n\nclass PayPalProcessor(PaymentProcessor):\n def __init__(self, email):\n self.email = email\n\n def charge(self, amount):\n print(f\"Charging ${amount:.2f} from PayPal account {self.email}\")\n\n def refund(self, amount):\n print(f\"Refunding ${amount:.2f} to PayPal account {self.email}\")\n\ndef run_checkout(processor, amount):\n print(processor.describe())\n processor.charge(amount)\n\nrun_checkout(CreditCardProcessor(\"4242\"), 49.99)\nrun_checkout(PayPalProcessor(\"alice@example.com\"), 29.99)\n```\n\n\n`PaymentProcessor` declares the contract: every subclass must implement `charge` and `refund`. It also provides a concrete `describe` method that all subclasses inherit for free. Abstract classes can mix abstract and concrete methods; only the abstract ones are required overrides.\n\n`run_checkout` takes any `PaymentProcessor` and uses it polymorphically. The function doesn't know or care which subclass it received. If a new payment method appears (Apple Pay, store credit, bank transfer), it slots in by inheriting from `PaymentProcessor` and implementing the two abstract methods. Every existing caller keeps working.\n\nThe same pattern fits other contracts. A `Shippable` abstract class with `weight` and `dimensions` abstract properties lets a shipping calculator handle books, electronics, clothing, anything that exposes the right two attributes. A `Discountable` abstract class with an abstract `apply_discount(percent)` method lets a promotion engine work on any item type without knowing which one it has.","pageType":"python"}

Abstract Classes

Get Premium