Interfaces

An interface acts as the contract that governs how objects interact. It defines the signatures of the properties and methods an object must have, forcing every implementing class to include them. In a large project with many developers, that means new objects follow an agreed-upon skeleton, which improves consistency and maintainability.

The role of an interface goes beyond defining an object’s structure. It is also central to realising object-oriented design principles such as polymorphism and the Dependency Inversion Principle.

In most cases an interface carries no implementation of its own, but several recent languages (Java 8’s default methods, C#’s default interface methods, and so on) allow a default implementation. Those defaults are convenient, yet they have been criticised for eroding the purely abstract nature of an interface, so when and how to use them deserves careful thought.

Classes are also limited in how much they can inherit, whereas a class can implement any number of interfaces — a real source of flexibility. That said, when several interfaces share a method signature you can run into unintended collisions or precedence problems, so interface design should give each method an intuitive role and name to avoid confusion.

Packing unrelated capabilities into a single interface — forcing many different objects to implement one interface — creates problems similar to a God Class. An interface should therefore be designed so that its purpose and role are obvious, and gratuitous abstraction is best avoided.

In short, interfaces define the contracts between objects, guaranteeing a consistent structure and interaction, and they are essential to realising object-oriented principles such as polymorphism and dependency inversion. Even while taking advantage of default implementations and multiple implementation, keep in mind that using them well takes clear criteria and deliberate design.