Protocols vs. Abstract Base Classes in Python: Choosing the Right Tool for Design

For many years I have worked on Python projects ranging from large enterprise systems to modular libraries, and a recurring challenge is defining object behavior in a clear, maintainable, and extensible way. Python offers two powerful tools for this purpose: Protocols and Abstract Base Classes (ABC).

Dynamic Duck‑Typed Protocols

If you have used Python’s dynamic duck‑typing, you know the freedom (and chaos) of relying on objects to "quack" in a certain way. Protocols formalize this idea using type hints. Introduced in the typing module (Python 3.8+), a protocol defines a set of methods or attributes an object must implement to be considered compatible, without requiring explicit inheritance; any object with the required members satisfies the protocol.

Data‑Processing Example

Consider a financial analysis tool that processes data from APIs, databases, and CSV files. Each data source object provides read and write methods but shares no common base class. A protocol lets us ensure these objects work with a shared processing function without refactoring.

<code>from typing import Protocol

class DataSource(Protocol):
    def read(self) -> str:
        ...
    def write(self, data: str) -> None:
        ...

class APIClient:
    def read(self) -> str:
        return "Data from API"
    def write(self, data: str) -> None:
        print(f"Sending data to API: {data}")

class CSVHandler:
    def read(self) -> str:
        return "Data from CSV"
    def write(self, data: str) -> None:
        print(f"Writing to CSV: {data}")

def process_data(source: DataSource) -> None:
    data = source.read()
    print(f"Processing: {data}")
    source.write("Processed data")

api_client = APIClient()
csv_handler = CSVHandler()

process_data(api_client)  # Works with APIClient
process_data(csv_handler)  # Works with CSVHandler</code>

This approach allows the function to accept any object that satisfies the protocol, which is why protocols work well in this scenario:

The protocol defines the required read and write methods for any object passed to process_data .

Both APIClient and CSVHandler implement these methods without inheriting from a common base.

The flexibility ensures the system remains extensible – new data‑source types can be added without modifying existing code.

In my experience, protocols are especially useful when dealing with legacy code or integrating third‑party libraries because they provide type safety without forcing a refactor.

How Protocols Work

Under the hood, Python uses a metaclass to make protocols act as both type hints and runtime validators. When you define a protocol, Python creates a special metaclass that performs structural type checking, meaning an object is considered a virtual subclass of the protocol if it implements the required methods and attributes.

<code>print(issubclass(APIClient, DataSource))  # True
print(isinstance(csv_handler, DataSource))  # True</code>

Note that neither class explicitly inherits from DataSource , but the metaclass mechanism ensures they satisfy the protocol because they implement read and write .

If you need runtime validation, you must use the @runtime_checkable decorator from typing :

<code>from typing import runtime_checkable

@runtime_checkable
class DataSource(Protocol):
    def read(self) -> str:
        ...
    def write(self, data: str) -> None:
        ...

print(isinstance(api_client, DataSource))  # True</code>

This flexibility makes protocols powerful for type checking while preserving Python’s dynamic nature.

Abstract Base Classes for Design‑Time Structure

While protocols are highly flexible, sometimes a more structured approach is needed. Abstract Base Classes (ABC) enforce a strict interface by requiring explicit inheritance, making them ideal when you want to define a clear hierarchy from the start.

ABCs are useful during system design because they ensure all subclasses follow a common contract.

Report Plugin Example (Using ABC)

Imagine a system where each plugin generates a report and needs specific configuration. An ABC can enforce that all plugins implement generate_report and configure methods.

<code>from abc import ABC, abstractmethod

class ReportPlugin(ABC):
    @abstractmethod
    def generate_report(self, data: dict) -> str:
        """Generate a report based on the given data."""
        pass

    @abstractmethod
    def configure(self, settings: dict) -> None:
        """Configure the plugin with specific settings."""
        pass

class PDFReportPlugin(ReportPlugin):
    def generate_report(self, data: dict) -> str:
        return f"PDF Report for {data['name']}"
    def configure(self, settings: dict) -> None:
        print(f"Configuring PDF Plugin with: {settings}")

class HTMLReportPlugin(ReportPlugin):
    def generate_report(self, data: dict) -> str:
        return f"HTML Report for {data['name']}"
    def configure(self, settings: dict) -> None:
        print(f"Configuring HTML Plugin with: {settings}")

def run_plugin(plugin: ReportPlugin, data: dict, settings: dict) -> None:
    plugin.configure(settings)
    report = plugin.generate_report(data)
    print(report)

pdf_plugin = PDFReportPlugin()
run_plugin(pdf_plugin, {"name": "John Doe"}, {"font": "Arial"})

html_plugin = HTMLReportPlugin()
run_plugin(html_plugin, {"name": "Jane Smith"}, {"color": "blue"})</code>

In this example:

All plugins must explicitly inherit from ReportPlugin and implement the required methods.

The function run_plugin can operate on any plugin without knowing its details.

Adding new plugins is straightforward, and the shared interface guarantees consistency.

When to Use Protocols vs. ABCs

Choosing between protocols and ABCs depends on the project context:

Use Protocols When

You are working with existing code or third‑party libraries.

Flexibility is paramount and you do not want to enforce a strict hierarchy.

Objects from unrelated class hierarchies need to share behavior.

Use ABCs When

You are designing a system from scratch and need to enforce structure.

Class relationships are predictable and inheritance makes sense.

Shared functionality or default behavior can reduce duplication and improve consistency.

Reflection

In my experience, protocols and ABCs are complementary rather than competing tools. I use protocols to add type safety to legacy systems without heavy refactoring, while I rely on ABCs when building new systems where clear structure and consistency are essential.

When deciding which to adopt, consider the flexibility requirements and long‑term goals of your project: protocols provide seamless integration and flexibility, whereas ABCs help establish robust architecture and maintainability.