Interface Use Cases

• API design
• documentation
• testing
• code generation
• validation
• adaptation
• static analysis
• run-time introspection

API design

In truth, API design is simply the process of defining interfaces.

documentation

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.

testing

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.

code generation

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.

validation

With programmatic interfaces, making sure some code implements an interface properly is straight-forward.

adaptation

Programmatic interfaces allow adaptation systems (a la PEP 246) to be smarter when adapting objects.

static analysis

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.

run-time introspection

Defined-by-code interfaces allow for run-time inspection of those interfaces for dynamic behavior.