Category Archives: integration-segregation-principle

Integration Segregation Principle

This blog is about the Integration Segregation Principle (ISP) based off of the “SOLID: Integration Principle” article by Anu Viswan. This topic relates to the course (CS343) because we will cover SOLID, a combination of principles which contains ISP.
Integration Segregation Principle is about organizing your interfaces in a way where you will not be implementing methods that are not needed in your subclasses. The example given in the article by Viswan contains an IPrinter interface with an All-In-One Printer class and an Economical Printer class. The example that shows bad technique in ISP displays the IPrinter interface with three methods: print(), scan(), and copy(). For the All-In-One Printer class this is fine since as it has the functionality of all three methods. However, the Economical Printer class only prints. This leaves us putting exceptions in the scan() and copy() methods. This could lead to a violation of the Liskov Substitution Principle and is also known as a “fat interface” or “interface bloat”.
This problem is most noticeable when each of the implementations have separate assemblies. When making a change in the interface, all of the assemblies have to be rebuilt even if it seems as there is no change in their functionality. ISP reduces the impact when making changes.
The example of the correct way to build the IPrinter interface as given by Viswan would be to create smaller interfaces with an IPrinter interface containing the print() method, an ICanScan interface containing the scan() method, and an ICanCopy interface containing the copy() method. Now, the Economic Printer class can implement only the IPrinter class with the methods it supports. Meanwhile, the All-In-One Printer class can implement each of the new interfaces giving it all the additional features.
One side note about this example that Viswan added to the end that I found important to clarify is that this does not mean that all interfaces should have only one method but that we should understand the responsibilities of the interface.
I chose this topic because I think it is an essential rule to follow in order to have a solid and well-rounded class hierarchy that will not cause problems down the road. I chose Viswans article in particular because the content by Viswan on the rest of the SOLID principles seem very reliable, accurate, and well thought out. This will be of great importance when designing our final projects for this course.


From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.