What the ABC?
What are Abstract Base Classes good for? A while ago I had a discussion about which pattern to use for implementing a maintainable class hierarchy in Python. More specifically, the goal was to define a simple class hierarchy for a service backend in the most programmer-friendly and maintainable way.
There was a
BaseService that defines a common interface and several concrete implementations that do different things but all provide the same interface (
RealService, and so on). To make this relationship explicit the concrete implementations all subclass
To be as maintainable and programmer-friendly as possible the idea was to make sure that:
- instantiating the base class is impossible; and
- forgetting to implement interface methods in one of the subclasses raises an error as early as possible.
When to Use Python’s
This raises the question why you’d want to use Python’s
abc module. The above design problem is pretty common in more complex systems. To enforce that a derived class implements a number of methods from the base class we can use something like this Python idiom:
class Base: def foo(self): raise NotImplementedError() def bar(self): raise NotImplementedError() class Concrete(Base): def foo(self): return 'foo() called' # Oh no, we forgot to override bar()... # def bar(self): # return "bar() called"
So, what do we get from this first implementation? Calling methods on an instance of
Base correctly raises
>>> b = Base() >>> b.foo() NotImplementedError
Furthermore, instantiating and using
Concrete works as expected—and, if we call an unimplemented method on it like
bar() this also raises an exception:
>>> c = Concrete() >>> c.foo() 'foo() called' >>> c.bar() NotImplementedError
This first implementation is decent but it isn’t perfect yet. The downsides here are that we can still:
Basejust fine without getting an error; and
- provide incomplete subclasses—instantiating
Concretewill not raise an error until we call the missing method
abc module was added in Python 2.6, we can do quite a bit better and solve these outstanding issues. Here’s an updated implementation using an Abstract Base Class defined with the
from abc import ABCMeta, abstractmethod class Base(metaclass=ABCMeta): @abstractmethod def foo(self): pass @abstractmethod def bar(self): pass
class Concrete(Base): def foo(self): pass # We forget to declare bar() again...
This still behaves as expected and creates the correct class hierarchy:
assert issubclass(Concrete, Base)
Yet, we do get something awesome here. Subclasses of
Base raise a
TypeError at instantiation time whenever we forget to implement any abstract methods. The raised exception tells us which method or methods we’re missing:
>>> c = Concrete() TypeError: "Can't instantiate abstract class Concrete with abstract methods bar"
abc we’d only get a
NotImplementedError if a missing method is actually called. Being notified about missing methods at instantiation time is a great advantage. It makes it more difficult to write invalid subclasses. This might not be a big deal writing new code, but a few weeks or months down the line I promise it’ll be helpful.
This pattern is not a full replacement for static-typing, of course. But in some situation it can make the resulting code more robust and more readily maintainable. Also, using
abc states the code’s intent more clearly. I’d encourage you to read the
abc module documentation and to start applying this pattern where it makes sense.