The interface segregation principle is concerned with keeping interfaces highly cohesive, engaged in only one task or a set of tasks that are highly related. It states that no client should be forced to depend on methods that it does not use.
This principle is similar in spirit to the principle of single responsibility: its goal is to ensure that you create focused and highly-cohesive abstractions that are only concerned with a single area of responsibility. But instead of making you consider the concept of responsibility itself, it makes you look at the interfaces that you're creating and consider whether they're appropriately segregated.
Consider a local government office. They have a paper form (let's call it Form 1A) that it uses to change a person's details. It is a form that's existed for over 50 years. Via this form, a local citizen can change a number of their details, including, but not limited to, the following:
- A change of name
- A change of marital status
- A change of address
- A change of council tax discount status (student/elderly)
- A change of disability status
As you can imagine, it's a very complex and dense form, with many independent sections that a citizen must ensure they fill out correctly. We've all likely been exposed to the bureaucratic complexity of government paperwork, as shown in the following:
Form 1A provides a set of interfaces to the various change functions that are provided by the local government office. The interface segregation principle asks us to consider whether this form is forcing its clients to depend on methods that they don't use. In this context, the clients are the users of the form, the citizens, and the methods are all of the available functions that the form provides: the ability to register a name change, an address change, and so on.
As is hopefully obvious by now, Form 1A does not follow the interface segregation principle very well. If we were to redesign it, we would likely separate out the individual functions it serves into their own independent forms. The way we'd do this is by employing something we learned at the beginning of the chapter: the principle of least information (LoD), which asks us a very simple question: What's the least amount of information each abstraction (for example, changing one's address) requires? We can then choose to only include in each form what is needed to fulfill its function:
To separate out and then only include the necessary fields in paper forms such as these may seem quite obvious, but it's something programmers continually neglect to do effectively within their coded abstractions. The interface segregation principle reminds us of the importance of properly separating out our abstractions into interfaces that are distinct and internally cohesive. Doing so has the following benefits:
- Increased reliability: Having properly isolated interfaces that are truly decoupled makes code easier to test and verify, thereby aiding its general reliability and stability over time.
- Increased maintainability: Having segregated interfaces means that changes to one needn't affect the others. As we saw in the layout of Form 1A, the positioning and space available are heavily dependent on each part of the form. Once we have decouple these dependencies, however, we are free to maintain and change each one as we see fit, without worrying about the others.
- Increased usability: Having interfaces that are separated according to their purpose and function means that users are able to understand and navigate the interfaces with far less time and cognitive effort. The users are the consumers of our interfaces, and so are the most dependent on the interfaces being clearly delineated.