12/21/24, 8:46 PM SOLID — Interface Segregation Principle (Part 4) | by Matthias Schenk | Towards Dev
Search Write Sign up Sign in
SOLID — Interface Segregation
Principle (Part 4)
Matthias Schenk · Follow
Published in Towards Dev · 5 min read · Jul 4, 2023
Three parts of my series about the SOLID principles are finished but still two
remains. Today it is time for the fourth one, represented by the I in SOLID-
the Interface Segregation Principle (ISP). It is a principle that has similar
goals as the Single Responsibility Principle, which emphasizes that a class or
function should only have one responsibility and one reason to change.
Transfering this to interfaces leads to ISP.
What is the Interface Segregation Principle?
ISP suggests that clients should not be forced to depend on interfaces they
do not use. In other words, it encourages developers to create fine-grained
interfaces customized specifically to the needs of the clients.
The principle emphasizes the importance of designing interfaces that are
focused and specific to the clients that use them. It suggests that interfaces
should be segregated into smaller and more cohesive units, rather than
having a single large interface that covers all possible scenarios. This allows
clients to depend only on the interfaces that are relevant to their needs,
reducing the potential for unnecessary dependencies and tight coupling.
As already mentioned above this sounds a lot like the Single Responsibility
Principle. By focussing on a single responsibility in an interface, the scope
automatically stays limited and the behavior, which is provided, has a high
cohesion. With this the clients mostly will use all provided functionality, not
only parts out of it.
By following the Interface Segregation Principle, I can achieve several
benefits in my software projects:
https://towardsdev.com/solid-interface-segregation-principle-part-4-73f850af2248 1/7
12/21/24, 8:46 PM SOLID — Interface Segregation Principle (Part 4) | by Matthias Schenk | Towards Dev
Modularity: Segregating interfaces into smaller units promotes
modularity, making it easier to understand and modify code. Modules
become more focused, and changes made to one module have minimal
impact on other parts of the system.
Reduced Dependencies: Clients that depend on interfaces do not need to be
coupled to unnecessary methods or functionalities they don’t use. This
reduces the number of dependencies and simplifies the codebase,
leading to improved maintainability.
Testability: Interfaces that are designed with the ISP in mind make it
easier to write meaningful unit tests. With smaller, focused interfaces, it
becomes simpler to isolate and test individual components, leading to
more effective testing strategies.
Flexibility: The ISP enables greater flexibility by allowing clients to
implement only the interfaces that are relevant to their specific
requirements. This allows for easier adaptation and customization of
code, promoting code reuse and extensibility.
In the next part I will have a look on a practical example.
Example
To better understand the Interface Segregation Principle, let’s consider an
example where the intention of the principle is violated. Suppose I’m
building a media player library that supports audio and video playback.
Initially, I create a single interface called MediaPlayer to handle both audio
and video playback:
interface MediaPlayer {
fun playAudio()
fun playVideo()
fun pause()
fun stop()
}
In this case, the MediaPlayer interface violates the Interface Segregation
Principle because clients that only require audio playback functionality are
forced to depend on methods related to video playback. This creates
unnecessary dependencies and makes the interface less cohesive. In
practice, the video player implementation will have an empty playAudio() -
function, the same is true for the audio player implementation for the
playVideo() - function. In code this often leads to the usage of the
UnsupportedOperationExceptions which states, that the function should not be
used in this context. This is not what I expect when calling functions on an
object.
To address the violation of the Interface Segregation Principle, I can
segregate the interface into more focused units that create specific
requirements. Let’s create separate interfaces for audio and video playback:
https://towardsdev.com/solid-interface-segregation-principle-part-4-73f850af2248 2/7
12/21/24, 8:46 PM SOLID — Interface Segregation Principle (Part 4) | by Matthias Schenk | Towards Dev
interface AudioPlayer {
fun playAudio()
fun pause()
fun stop()
}
interface VideoPlayer {
fun playVideo()
fun pause()
fun stop()
}
Now, clients can depend on the specific interfaces they require. For
example, a client responsible for audio playback functionality can depend on
the AudioPlayer interface without being burdened with video-related
methods. Similarly , a client responsible for video playback functionality can
depend on the VideoPlayer interface without being forced to implement
unnecessary audio-related methods. This segregation of interfaces improves
the modularity, reduces dependencies, and enhances the maintainability of
the codebase.
By caring about the Interface Segregation Principle, I have achieved a more
flexible and cohesive design. Clients can now implement and utilize only the
interfaces that are relevant to their specific requirements, promoting code
reusability and extensibility.
In the above example it is also possible to further extract an interface that
provides the common behavior of both interfaces - pause() and stop(). So it is
not necessary to duplicate this in multiple interfaces.
interface Playable{
fun pause()
fun stop()
}
interface AudioPlayer: Playable {
fun playAudio()
}
interface VideoPlayer: Playable {
fun playVideo()
}
A very popular example of a violation of the Interface Segregation Principle
are unmodifiable collections in Java.
String[] colors= { "blue", "green", "yellow", "red"};
List<String> colorList = Arrays.asList(flowers);
colorList.add("Celosia");
https://towardsdev.com/solid-interface-segregation-principle-part-4-73f850af2248 3/7
12/21/24, 8:46 PM SOLID — Interface Segregation Principle (Part 4) | by Matthias Schenk | Towards Dev
The above code is leading to an UnsupportedOperationException because the
Arrays.asList(…) - function is returning an list, that is unmodifiable, but
because it implements the List interface, it contains an add(…) - function. So
it is possible to call this method even if it is not intended.
Exception in thread "main" java.lang.UnsupportedOperationException
at java.base/java.util.AbstractList.add(AbstractList.java:153)
at java.base/java.util.AbstractList.add(AbstractList.java:111)
at Program.main(Program.java:9)
Kotlin does not have this problem with collections because there is a
distinction between immutable and mutable collections. So there is no need
to “disable” functions by throwing an exception.
I hope this examples makes it clear what the essence of the ISP is.
Conclusion
Together with the Single Responsibility Principle the Interface Segregation
Principle is a valuable guideline in software development that promotes the
design of small and cohesive interfaces. These are focusing on providing an
API that is used completely by all consuming clients. There is only one
responsibility of the interface and so also only one reason to use it. This
prevents using one interface because of different reasons, which contains
the risk, that there are clients using only partitions of the API.
To evaluate if there is a violation of the ISP it can help to check the consumer
of an interface. Do all of them use all the provided methods? Are there
different use-cases? If the second question answers to yes, you should think
about splitting the interface to multiple smaller ones, every only contain a
subset of cohesive functions.
In the last part of my series I will talk about the Dependency Inversion
Principle.
Software Engineering Software Architecture Clean Code Principles
Published in Towards Dev Follow
5.1K Followers · Last published 1 day ago
A publication for sharing projects, ideas, codes, and new theories.
https://towardsdev.com/solid-interface-segregation-principle-part-4-73f850af2248 4/7
