This principle says:
“Clients should not be forced to implement unnecessary methods which they do not use”
Let’s take an example. A Developer is created an interface Reportable and added two methods generateExcelReport() and generatedPdfReport(). Now a client wants to use this interface but he intends to use reports only in PDF format and not in excel. Will he be able to use the functionality easily?
Really Not. The client has to implement both the methods, out of which one is an extra burden put on them by the designer of software. Either Client will implement another method or leave it blank. This is not a good design.
So, what is the best solution? The solution is to create two interfaces by breaking the existing interface. They should be like PdfReportable and ExcelReportable. This will give the flexibility to the user or client to use or implement only the required functionality.
Why is this principle required?
Let us assume that there is a Restaurant interface which contains methods for accepting orders from walk-in customers, online customers, and telephone customers. It also contains methods for handling online payments (for online customers) and in-person payments (for walk-in customers as well as telephone customers when their order is delivered at home).
You May Also Like:
Adapter Pattern
Decorator Pattern
Facade Pattern
Proxy Pattern
Composite Pattern
Flyweight Pattern
Bridge Pattern
That’s all about Interface Segregation Principle (ISP)
If you have any feedback or suggestion please feel free to drop in below comment box.