Welcome back to Class Machinery: Dataclasses, Descriptors, Metaclasses! You've made excellent progress, having mastered advanced dataclasses for robust data containers and descriptors for sophisticated attribute validation. In our previous lesson, you built reusable Range descriptors that provide centralized validation logic across multiple classes and attributes.

Today, we're exploring the powerful combination of Abstract Base Classes (ABCs) and class hooks to build extensible plugin architectures. While descriptors give us control over attribute access, ABCs and class hooks let us control class creation and enforce contracts across inheritance hierarchies. This combination is perfect for building systems where new functionality can be added simply by defining new classes that follow established protocols.

We'll construct a self-registering plugin system that automatically discovers concrete implementations while enforcing abstract contracts. Using abc.ABC for interface definitions and __init_subclass__ for automatic registration, we'll build a transformation pipeline where plugins are discovered, validated, and executed in priority order. By the end, you'll understand how to create extensible architectures that grow naturally as new requirements emerge.

In programming, a contract is a formal specification that defines the interface and behavioral expectations that implementing code must satisfy. It establishes what methods must exist, what parameters they accept, and what they should return, without dictating how the implementation achieves these requirements.

Abstract Base Classes serve as contracts in Python, defining interfaces that subclasses must implement while preventing the instantiation of incomplete classes. Combined with class hooks, they create powerful patterns for automatic registration and validation during class creation.

The abc module provides the infrastructure for creating abstract classes that cannot be instantiated until all abstract methods are implemented. This ensures that concrete subclasses adhere to the expected interface, catching implementation errors early and making code more reliable. Meanwhile, __init_subclass__ is a special method called automatically whenever a class is subclassed, allowing parent classes to inspect, validate, or register their children during class creation.

Together, these features enable plugin architectures where new functionality is added by simply defining classes that inherit from a base class. The parent can automatically discover and register these plugins while ensuring they implement the required interface, creating systems that are both extensible and safe.

Our plugin system starts with a base class that maintains a registry of all concrete implementations. This registry will automatically populate as new plugin classes are defined, providing a central location for plugin discovery and execution.

The PluginBase class inherits from ABC to provide abstract base class functionality, ensuring it cannot be instantiated directly. The registry class variable uses ClassVar to indicate it belongs to the class itself rather than individual instances. The list contains class objects (not instances), allowing us to maintain a catalog of available plugin types. The forward reference type["PluginBase"] ensures proper type hinting even though we're defining the class that contains this annotation.

The __init_subclass__ method is where the magic of automatic plugin discovery happens. This class hook is called every time someone creates a new class that inherits from PluginBase, giving us the opportunity to register, validate, or modify the new class.

The method signature includes register: bool = True as a keyword-only parameter, allowing subclasses to opt out of registration by passing register=False. The inspect.isabstract(cls) check ensures we only register concrete classes that have implemented all required abstract methods. This prevents incomplete classes from appearing in the registry while still allowing abstract intermediate classes in the inheritance hierarchy. The registry is kept sorted by a priority attribute (defaulting to 100), ensuring plugins execute in the correct order.

The abstract method contract defines what every plugin must implement. This creates a stable interface that the plugin system can rely on while allowing individual plugins to provide their own specialized behavior.

The @abstractmethod decorator ensures that PluginBase cannot be instantiated and that any subclass must implement the execute method. This method signature establishes our plugin contract: each plugin receives a dictionary payload and returns a modified version. The consistent interface allows the plugin system to treat all plugins uniformly, while each plugin provides its own transformation logic. Any class that inherits from PluginBase but fails to implement execute will remain abstract and won't be registered automatically.

Many plugins will follow similar patterns, so we can create specialized abstract base classes that provide common functionality. This creates a hierarchy where plugins can inherit appropriate behavior while still participating in the registration system.

BaseTransform introduces a more specific contract with a transform method while providing a standard execute implementation. This pattern allows transform-focused plugins to implement the simpler transform interface rather than worrying about the broader execute contract. The execute method serves as a template method that calls the specialized transform implementation. Since BaseTransform still has an abstract method (transform), it won't be registered in the plugin system, but its concrete subclasses will be.

Now we can build concrete plugins that provide actual functionality. Each plugin focuses on a specific transformation while participating automatically in the registration and execution system.

UpperCaseNames provides a concrete implementation of the transform interface, converting the "name" field to uppercase when present. The priority = 10 attribute ensures this plugin runs early in the pipeline. The implementation is defensive, checking for the presence and validity of the "name" field before transformation. Creating a new dictionary prevents unintended side effects on the original payload, following immutable transformation principles that make plugin pipelines more predictable and easier to debug.

Some plugins may need more control over the execution process than the transform pattern provides. These plugins can implement the execute method directly while still participating in the registration system.

AddTax implements execute directly to handle precise decimal arithmetic for financial calculations. The plugin converts the amount to Decimal for precision, applies a 10% tax, and rounds to two decimal places using banker's rounding. Converting back to a string maintains compatibility with the payload format while preserving precision. The higher priority (20) ensures this runs after name processing, demonstrating how plugins can be ordered to create meaningful transformation sequences.

The registration system includes mechanisms for plugins to opt out when they shouldn't be part of the active plugin set. This is useful for utility classes, base classes, or plugins that should only be used in specific contexts.

The register=False parameter in the class definition tells __init_subclass__ to skip adding this class to the registry. This plugin implements the required execute method (making it concrete), but it won't participate in automatic plugin execution. This pattern is valuable for test plugins, utility classes, or conditional plugins that should only be activated under specific circumstances. The class is fully functional but operates outside the automatic discovery system.

The plugin execution system processes the registry to apply all registered plugins in priority order. This creates a pipeline where each plugin can build upon the transformations made by previous plugins.

The run_all function creates a copy of the input payload and passes it through each registered plugin in order. Each plugin receives the output of the previous plugin, creating a transformation chain. Plugin classes are instantiated fresh for each execution, ensuring clean state and preventing cross-execution contamination. This approach allows plugins to be stateless while still participating in complex transformation pipelines where order and state management matter.

Let's verify our plugin system works correctly by examining the registry, running transformations, and testing the abstract base class behavior.

This test suite verifies every aspect of our plugin system: registry population, plugin execution, and abstract class enforcement. We check that exactly two plugins are registered, run a transformation pipeline, and verify that abstract classes and opt-out plugins are handled correctly.

The output confirms our system works perfectly. Two plugins are registered in priority order, the transformation pipeline successfully processes the data (uppercasing the name and adding tax), and the abstract base classes are properly excluded from the registry. The final TypeError demonstrates that abstract classes cannot be instantiated, ensuring our contracts are enforced at runtime. This provides a robust foundation for extensible plugin architectures.

Outstanding work mastering the powerful combination of Abstract Base Classes and class hooks! You've built a sophisticated plugin architecture that automatically discovers concrete implementations, enforces interface contracts, and executes transformations in priority order. The system elegantly handles abstract intermediate classes, provides opt-out mechanisms, and maintains a clean separation between plugin registration and execution.

The __init_subclass__ hook demonstrates Python's metaprogramming capabilities, allowing classes to participate in their own inheritance hierarchy management. Combined with ABC contracts, this creates systems that are both flexible and safe: new plugins can be added simply by defining classes that inherit from the appropriate base, while the abstract method requirements ensure these plugins implement the expected interface.

This pattern is incredibly powerful for building extensible applications where functionality grows over time. Whether you're building data processing pipelines, web middleware systems, or plugin-based applications, this architecture provides the foundation for maintainable and scalable designs.

Next, we'll explore metaclasses, the ultimate level of Python's class machinery that gives you control over class creation itself. But first, prepare to put your new skills to the test with challenging exercises that will have you extending the plugin system, debugging registration issues, and building sophisticated validation layers!