Are ABCs an anti-pattern?
demianbrecht at gmail.com
Sun Oct 7 00:45:23 CEST 2012
On 12-10-05 12:58 PM, Trent Nelson wrote:
> I like them. In particular, I like that I can enumerate all the
> subclasses that happen to implement the ABC via the metaclass's
> __subclasses__() method.
As long as you have a common base class (which in your case is a
requirement), then __subclasses__ works for introspecting child classes.
It doesn't *really* have anything to do with abcs.
> I also like that I can trust Python
> not to instantiate a subclass of an ABC unless it meets all the
> interface criteria I've stipulated.
Another way to read this is that you don't trust those using your code
to be bright enough to understand what your code is doing and what it
requires. In my mind, this seems to somewhat contradict the philosophy
of "we're all consenting adults here". Whether you utilize interfaces or
not, code should be documented. Your documentation would be responsible
for laying out the expected interface (again, whether you're using the
interfaces or not). Code would fail at some point if a requirement on an
interface hasn't been filled. The *one* nice thing is that it'll error
on import rather than execution time, but to me, if your code is unit
tested, then all these things should be caught almost immediately anyway.
From my experience (again, *only* talking about Python here), it seem
to me that less is generally more. Less code means less things to read
and tie together, making it easier to grok overall (not to mention less
overhead for the interpreter, but that's virtually moot due to the
*very* little overhead in 99% of cases of uses features such as abcs).
Using abcs not only lends itself to code bloat, but it also leads to
over-engineering as once you fall into old OOP habits, you start getting
back to un-Pythonic code (pretty subjective statement, I know :)).
Again, please don't misunderstand my intentions here. I'm not arguing
the need for abstract base classes in a strict OOP world. I'm arguing
them as not genuinely being Pythonic.
Thanks for your the feedback so far.
More information about the Python-list