Interface Segregation Explained - SOLID Design Principles | Example Java Code Demo | InterviewDOT

Tamil Interface Segregation Explained - SOLID Design Principles | InterviewDOT

According to Robert Martin, The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

The ISP was first used and formulated by Robert C. Martin while consulting for Xerox. Xerox had created a new printer system that could perform a variety of tasks such as stapling and faxing. The software for this system was created from the ground up. As the software grew, making modifications became more and more difficult so that even the smallest change would take a redeployment cycle of an hour, which made development nearly impossible.

The design problem was that a single Job class was used by almost all of the tasks. Whenever a print job or a stapling job needed to be performed, a call was made to the Job class. This resulted in a 'fat' class with multitudes of methods specific to a variety of different clients. Because of this design, a staple job would know about all the methods of the print job, even though there was no use for them.

The solution suggested by Martin utilized what is today called the Interface Segregation Principle. Applied to the Xerox software, an interface layer between the Job class and its clients was added using the Dependency Inversion Principle. Instead of having one large Job class, a Staple Job interface or a Print Job interface was created that would be used by the Staple or Print classes, respectively, calling methods of the Job class. Therefore, one interface was created for each job type, which was all implemented by the Job class.

“Clients should not be forced to depend upon interfaces that they do not use.” — Robert Martin, paper “The Interface Segregation Principle”

Abstraction is the heart of object-oriented design. It allows the client to be unconcerned with the implementation details of functionality. In Java, abstraction is achieved through abstract classes and interfaces. This article explains the idea of the Interface Segregation Principle, which is the “I” in the SOLID principles.

What Is the Interface Segregation Principle?
The Interface Segregation Principle (ISP) states that a client should not be exposed to methods it doesn’t need. Declaring methods in an interface that the client doesn’t need pollutes the interface and leads to a “bulky” or “fat” interface.

A Bulky Interface
In bulky interfaces, there are too many operations, but for most objects, these operations are not used. The ISP tells us that we should need most or all methods of an interface, and in a bulky interface, we most commonly only need a few of them in each case. Also, when testing a bulky interface, we have to identify which dependencies to mock and potentially have a giant test setup.

Unused Dependencies
Another indication of an ISP violation is when we have to pass null or equivalent value into a method. In our example, we can use orderCombo() to place a burger-only order by passing zero as the fries parameter. This client does not require the fries dependency, so we should have a separate method in a different interface to order fries.

Methods Throwing Exceptions
As in our burger example, if we encounter an UnsupportedOperationException, a NotImplementedException, or similar exceptions, it smells like a design problem related to the ISP. It might be a good time to refactor these classes.

Another benefit is that the Interface Segregation Principle increases the readability and maintainability of our code. We are reducing our class implementation only to required actions without any additional or unnecessary code.

[ganeskm]

Great Content. Superb explanation.. Looking eagerly for design pattern series...

[ArunKumar-gnvq]

Clear explained bro, kindly post LSP AND DIP principal using details.

[cloudtamil]

Good explanation# Looking full series of Design patterns if possible, please provide.

[sathishkumars]

short and sweet
please put a video on the last principle on SOLID design.

[tamilan]

hi sir, very crisp explanation, dependency inversion principle is not posted i think

[prakashkaruppusamy]

Arumai.. nanbare.. github code iruntha share panunga

[manikandankm]

Hello Sir, In this case we may be in the situation of creating multiple interfaces when we want a class which implements the methods of each interface is this correct ? can we create multiple interfaces according to the class needs ?