It states that no client should be forced to depend on methods it does not use. In other words, only relevant methods and functionalities should be exposed to clients and clients should have ability to pick and choose what’s relevant to them.<\/p>\n\n\n\n
The problem with creating large Interfaces and hence heavy classes is that every client may not require all the functionality offered by the large Interface but they end up including things they don’t use. This leads to a very common issue in the Software Life-cycle where things break as a side-effect of some other change. Unexpected errors may occur for a client when there are changes in certain areas of the underlying application (which are not even being used by the client).<\/p>\n\n\n\n
Interface Segregation can be considered an extension of Single Responsibility Principle which helps in segregating related but different functionalities. <\/p>\n\n\n\n
Consider the example of a generalized E-Commerce platform which can be utilized for sale & delivery of physical goods and electronic subscription. <\/p>\n\n\n\n
Classes which handle Delivery can be defined like this:<\/p>\n\n\n\n
![\"\"](\"https:\/\/saurabhjain.dev\/wp-content\/uploads\/2020\/12\/04-isp-01-delivery.png\")
<\/a><\/p>\n\n\n\n
Some of OrderDelivery <\/strong>methods like assignPostalServiceProvider()<\/em> may not be applicable for ElectronicDelivery. Clients that only require ElectronicDelivery<\/strong> will unnecessarily get the APIs specific to Physical Delivery. <\/p>\n\n\n\n Any changes related to Physical Delivery in the OrderDelivery<\/strong> interface, would require updates in the ElectronicDelivery<\/strong> concrete implementation too. It is useless but necessary change that can be avoided with proper segregation of Interfaces like:<\/p>\n\n\n\n The way classes are defined in Figure 2 is much cleaner and each class contains only relevant behavior.<\/p>\n\n\n\n Conclusion<\/strong><\/p>\n\n\n\n When each class contains only relevant functionality, then client applications are never impacted by unused dependencies. Interface Segregation helps in reducing side-effect bugs during the maintenance of Application.<\/p>\n","protected":false},"excerpt":{"rendered":" Interface segregation is another technique that helps in keeping the system loosely coupled by dividing the functionality into small components. The Interface Segregation Principle “I” It states that no client should be forced to depend on methods it does not use. In other words, only relevant methods and functionalities should be exposed to clients and … Continue reading SOLID Principles: Interface Segregation<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[34,41,42,55],"class_list":["post-499","post","type-post","status-publish","format-standard","hentry","category-design","tag-interface-segregation","tag-object-oriented-design","tag-object-oriented-programming","tag-solid-principles"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=\/wp\/v2\/posts\/499","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=499"}],"version-history":[{"count":1,"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=\/wp\/v2\/posts\/499\/revisions"}],"predecessor-version":[{"id":779,"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=\/wp\/v2\/posts\/499\/revisions\/779"}],"wp:attachment":[{"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=499"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=499"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/saurabhjain.dev\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=499"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}class ElectronicDelivery implements OrderDelivery {\n\n @Override\n public void assignPostalServiceProvider(String provider) {\n \/\/Do nothing\n }\n}<\/code><\/pre>\n\n\n\n<\/a>