On SOLID Code: I

The I in SOLID stands for “Interface Segregation” and is a hallmark of high quality, disciplined framework design: As system requirements change over time, there is often the temptation to short-circuit codepaths, to add just one more API to some class to make things just work. This is one of the ways in which code rot enters systems: One boundaries and responsibilities of systems are not clear, there is momentum towards tighter coupling/more brittleness in the system.

Interface segregation is something of a special case of single responsibility: An interface tells us that an object supports a certain set of operations, and interface segregation adds that that set of operations must have a maximal degree of cohesion. For example, an interface such as IObjectCache should really only have three methods: add, get, remove. It is tempting to start growing this interface, to add methods such as queryKeys, and getStatistics, increment, decrement, push and pop. As we add new methods, the interface becomes harder and harder for new implementations to support, and so decreases the usefulness of the interface. Breaking that interface down into a hierarchy allows classes to implement more or less capabilities, and clients to more clearly declare which particular set of capabilities they need. Goodness all around.