“No client should be forced to depend on methods it does not use”

Conceptually the simplest of the principles and one that is closely related to the SRP, the interface segregation principle is about finding the most appropriate abstractions in your code. The reason for this, is again, to protect against one avenue of change affecting other orthogonal ones.

Having to depend on an interface that has muddled concerns can lead to a lot of unwanted baggage. The bloat can leak into your code as you have to cater for cases you don’t care about. Upgrades come thick and fast but for features that you don’t use and with the risk that those changes will break those you do.

Overly complex interfaces are usually grown rather than designed. The slow drip feed of additional requirements, odd tweaks, and little hacks can snowball over the years to create a monster.

Strong interface and API design is an exercise in restraint. Cohesion is your guide here. Keep your interfaces cohesive, collecting together those concerns that change together, and free your clients from an extra burden.

Originally published at Better Programming