CS343 Blog Post for Week of November 6, 2023

SOLID Design Principles Explained: Interface Segregation with Code Examples

This week, I wanted to continue writing about the SOLID software design principles. We’ve reached the letter “I”, which represents the Interface Segregation Principle. I’ve been noticing a theme across the SOLID design principles that as many parts of your software as you can manage should be independent of one another, so that modifications can be made to a part without compromising the whole. The Interface Segregation Principle brings the relationship between the software user and designer into focus.

Once again defined by Robert C. Martin, the Interface Segregation Principle is “Clients should not be forced to depend upon interfaces that they do not use.” This principle goes hand-in-hand with the previously defined Single Responsibility Principle, which declares that “A class should have one, and only one, reason to change.” The goal of abiding by these principles is to produce code that is resilient to future modifications and fostering that resilience by building independent software components.

The article provides the real-life example of a years-old piece of software being iterated on. The designers may want to add new methods to existing interfaces, even though that may introduce new dependencies to the interface and violate the Single Responsibility Principle. The author introduces the term “interface pollution”, referring to the phenomenon of existing interfaces becoming cluttered with new methods that introduce new responsibilities to the interface, rather than building new interfaces that handle those responsibilities.

The author provides a practical example of this principle through another Coffee Machine implementation. A new EspressoMachine class is proposed but requires a new method that the BasicCoffeeMachine interface doesn’t include. The problem of interface pollution is illustrated simply in this example, when a brewEspresso() method is added to the CoffeeMachine interface to support the new EspressoMachine class. No other kinds of CoffeeMachine would use this method. This approach also introduces the issue that BasicCoffeeMachine could try calling brewEspresso(), or EspressoMachine could try calling brewFilterCoffee(), and either case would throw an exception.

The solution in this case is to create new interfaces from the existing CoffeeMachine interface, FilterCoffeeMachine and EspressoCoffeeMachine. This way, only the methods required by either type of concrete CoffeeMachine class can be accessed. This approach strengthens the independence of the concrete classes. If a new CoffeeMachine design demands methods from both interfaces, it can simply implement from both.

I chose to write about this topic because I’m still learning how to assign responsibilities to different parts of my software. Having interfaces that contain too many methods rather than continuing to further specialize them is an issue I’ve faced in software that I’ve written myself. Studying the SOLID principles and actively applying them to my work will help save me a lot of time and effort in my future projects.