Note: This is part of a series of articles reviewing the five SOLID Principles of object-oriented programming.
The Interface Segregation Principle is probably the most straight-forward of all the SOLID principles. It states:
“Clients should not be forced to depend on methods that they do not use.”
In dynamic languages, this isn’t really much of an issue because there is no way to define and force the implementation of interfaces on classes (like in Java). Instead, a set of methods determines whether or not an object implements an interface. If an object responds to “a particular set of methods”, it has implemented that “particular interface”.
In Ruby, modules can be used to define and share sets of methods across multiple classes. Using this construct, we can define different “interfaces”. So, when we say “keep our interfaces segregated”, we’re really saying “keep our modules segregated”. This leads to highly cohesive modules.
There are two main benefits to cohesive modules in Ruby: less coupling and more readable code.
By keeping our modules small and focused, we are simply applying the Single Responsibility Principle, but for modules. For example, let’s create a module called
Here, we have a set of common behaviors for phones. We can make use of this by including them in our class. Let’s create a
CellPhone class implements the methods in Phone! Any instance of
text other numbers.
Let’s create a new class called
Since we are overriding one of the methods in our module, it’s a sign our module isn’t cohesive enough. Our
RotaryPhone is being littered with methods it does’t need!
Another issue worth noting is the tight coupling between our two classes caused by sharing the same, non-cohesive module. Suppose we don’t override the
text method in
Any errors caused by
text in our Phone module would end up in both classes, even though
RotaryPhone doesn’t care about
text! This tight coupling between
RotaryPhone is unnecessary.
Segregate the Modules
A good solution for our problem is to segregate the basic phone behaviors from the mobile phone behaviors:
Now, each of our classes implement only the modules they require:
A Readable, Loosely-Coupled Solution
The behaviors of each class are more clearly defined by the explicitness of the modules it includes. Also,
RotaryPhone are only coupled by the methods in
BasicPhone, which makes sense since they both require the basic behaviors or
hangup. Both of our issues above are solved!
Although the Interface Segregation Principle is less important in dynamic languages like Ruby, it still leads to cohesive, readable classes. By keeping modules focused, we end up with looser coupling and cleaner “interface” definitions. They aren’t major wins, but wins nonetheless!