Interface Use Cases¶
- API design
- code generation
- static analysis
- run-time introspection
In truth, API design is simply the process of defining interfaces.
On the one hand, interfaces defined by your source act as self- documenting code, explicitly spelling out expectations syntactically. With appropriate tools, documentation can be generated from that code.
On the other hand, good documentation describes all public interfaces just as explicitly, though not programmatically. In fact, documentation is likely to capture aspects of interfaces that may be impractical to capture with syntax.
With interfaces, the expectations defined therein map directly to test cases. With sufficient syntactic support, explicit interfaces may be turned into unit tests directly (even automatically).
With a test-driven development approach, the tests effectively define the interfaces more explicitly than most syntactic solutions. Of course, they’re not the best means of communicating an interface.
Write an interface and then use a tool to generate skeleton code for implementations of the interface. This is definitely a feature of which IDEs take advantage.
With programmatic interfaces, making sure some code implements an interface properly is straight-forward.
Programmatic interfaces allow adaptation systems (a la PEP 246) to be smarter when adapting objects.
Interfaces defined in code allow for tools to provide programmatic analysis. The more detailed the definitions, the better the analysis. That’s the crux of static-typing and compile-time analysis/optimization. The idea of “contracts” takes the detail level to a level of its own.
Defined-by-code interfaces allow for run-time inspection of those interfaces for dynamic behavior.