<p>The Interface Segregation Principle (ISP) says that many client specific interfaces are better than one general purpose interface. Why is this important?</p>

[{'answer_id': 59008, 'author': 'aku', 'author_id': 1196, 'author_profile': 'https://Stackoverflow.com/users/1196', 'pm_score': 6, 'selected': True, 'text': '<p>ISP states that:</p>\n\n<blockquote>\n  <p>Clients should not be forced to depend\n  on methods that they do not use.</p>\n</blockquote>\n\n<p>ISP relates to important characteristics - <a href="http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29" rel="noreferrer">cohesion</a> and <a href="http://en.wikipedia.org/wiki/Coupling_%28computer_science%29" rel="noreferrer">coupling</a>.<br>\nIdeally your components must be highly tailored. It improves code robustness and maintainability. </p>\n\n<p>Enforcing ISP gives you following bonuses:</p>\n\n<ul>\n<li>High <a href="http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29" rel="noreferrer">cohesion</a> - better understandability, robustness</li>\n<li>Low <a href="http://en.wikipedia.org/wiki/Coupling_%28computer_science%29" rel="noreferrer">coupling</a> - better maintainability, high resistance to changes</li>\n</ul>\n\n<p>If you want to learn more about software design principles, get a copy\nof <a href="https://rads.stackoverflow.com/amzn/click/com/0135974445" rel="noreferrer" rel="nofollow noreferrer">Agile Software Development, Principles, Patterns, and Practices</a> book.</p>\n'}, {'answer_id': 59012, 'author': 'Bill the Lizard', 'author_id': 1288, 'author_profile': 'https://Stackoverflow.com/users/1288', 'pm_score': 3, 'selected': False, 'text': "<p>It simplifies the interface that any one client will use and removes dependencies that they might otherwise develop on parts of the interface that they don't need.</p>\n"}, {'answer_id': 59529, 'author': 'Mark Cidade', 'author_id': 1659, 'author_profile': 'https://Stackoverflow.com/users/1659', 'pm_score': 2, 'selected': False, 'text': '<p>One reason is that having many interfaces with a minimal amount of methods for each one makes it easier to implement each interface and to implement them correctly. A large interface can be unruly. Also, using a focused interface in a scenario makes the code more maintanable because you can see which facet of the object is being used (e.g., an IComparable interface lets you know that the object is only being used for comparisons in the given scenario). </p>\n'}, {'answer_id': 17999321, 'author': 'isJustMe', 'author_id': 571946, 'author_profile': 'https://Stackoverflow.com/users/571946', 'pm_score': 3, 'selected': False, 'text': '<p>The interface segregation is the “I” on the SOLID principle, before digging too deep with the first, let’s explain what’s does the latter mean. </p>\n\n<p>SOLID can be considered a set of best practices and recommendations made by experts (meaning they have  been proved before) in order to provide a reliable foundation in how we design applications. These practices strive to  make easier to maintain, extend, adapt and scale our applications.</p>\n\n<p><strong>Why should I care about SOLID programming?</strong></p>\n\n<p>First of all, you have to realize you are not going to be forever where you are. If we use standards and well known architectures, we can be sure that our code will be easy to maintain by other developers that come after us, and I’m sure you wouldn’t want to deal with the task of fixing a code that didn’t applied any known methodology as it would be very hard to understand it.</p>\n\n<p><strong>The interface segregation principle.</strong></p>\n\n<p>Know that we know what the SOLID principles are we can get into more detail about the Interface Segregation principle, but what exactly does the interface segregation says?</p>\n\n<blockquote>\n  <p>“Clients should not be forced to implement unnecessary methods which\n  they will not use”</p>\n</blockquote>\n\n<p>This means that sometimes we tend to make interfaces with a lot of methods, which can be good to an extent, however this can easily abused, and we can end up with classes that implement empty or useless methods which of course adds extra code and burden to our apps.\nImagine you are declaring a lot of methods in single interface, if you like visual aids a class that is implementing an interface but that is really needing a couple of methods of it would look like this:</p>\n\n<p><img src="https://i.stack.imgur.com/V6p8i.png" alt="enter image description here"></p>\n\n<p>In the other hand, if you properly apply the interface segregation and split your interface in smaller subsets you can me sure to implement those that are only needed:</p>\n\n<p><img src="https://i.stack.imgur.com/M0eWu.png" alt="enter image description here"></p>\n\n<p>See! Is way better!  Enforcing this principle will allow you to have low coupling which aids to  a better maintainability and high  resistance to changes. So you can really leverage the usage of interfaces and implementing the methods when you really should.\nNow let’s review a less abstract example, say you declared an interface called Reportable</p>\n\n<pre><code>public interface Reportable {\n\n        void printPDF();\n        void printWord();\n        void printExcel();\n        void printPPT();\n        void printHTML();\n\n\n}\n</code></pre>\n\n<p>And you have a client that will only to export some data in Excel format, you can implement the interface, but would you only have to implement the excel method? The answer is no, you will have to code the implementation for all the methods even if you are not going to use them, this can cause a lot of junk code hence making the code hard to maintain..</p>\n\n<p><strong>Remember keep it simple and don’t repeat yourself and you will find that you are already using this principle without knowing.</strong></p>\n'}, {'answer_id': 20562950, 'author': 'aknon', 'author_id': 2271385, 'author_profile': 'https://Stackoverflow.com/users/2271385', 'pm_score': 2, 'selected': False, 'text': '<p>This principle primarily serves twin purposes</p>\n\n<ul>\n<li><p>To make the code more readable and manageable.</p></li>\n<li><p>Promotes single responsibility for classes ( high cohesion ). Ofcourse why should a class have a method that has no behavioural impact ? Why not just remove it. Thats what ISP is about</p></li>\n</ul>\n\n<p>There are few questions that a designer must ask with concerns to ISP</p>\n\n<ul>\n<li>What does one achieve with ISP</li>\n<li>How to I analyse an already existing code for any ISP violations</li>\n</ul>\n\n<p>To take this discussion further, I must also add that this principle isn\'t a \'principle\' in the strictest sense, because under certain circumstances, applying ISP to the design, instead of promoting readability, might make the object structure unreadable and cluttered with unnecessary code. \nYou may well observe this in the java.awt.event package</p>\n\n<p>More at my blog: <a href="http://design-principle-pattern.blogspot.in/2013/12/interface-segregation-principle.html" rel="nofollow">http://design-principle-pattern.blogspot.in/2013/12/interface-segregation-principle.html</a></p>\n'}, {'answer_id': 40042398, 'author': 'Ravindra babu', 'author_id': 4999394, 'author_profile': 'https://Stackoverflow.com/users/4999394', 'pm_score': 2, 'selected': False, 'text': '<p><a href="https://en.wikipedia.org/wiki/Interface_segregation_principle" rel="nofollow noreferrer">ISP</a> is important.</p>\n<p>Basic idea of ISP : Client should not be forced to depend on methods it does not use.</p>\n<p>This principle seems to be more logical. Ideally client should not implement the methods, which are not used by the client.</p>\n<p>Refer to below SE question for code example:</p>\n<p><a href="https://stackoverflow.com/questions/9249832/interface-segregation-principle-program-to-an-interface/35382190#35382190">Interface Segregation Principle- Program to an interface</a></p>\n<p>Advantages:</p>\n<ol>\n<li><p><strong>Flexibility</strong> : In absence of ISP, you have one Generic FAT interface and many classes implementing it. Assume that you had 1 interface and 50 classes. If there is a change in interface, all 50 classes have to change their implementation.</p>\n<p>With ISP, you will divide generic FAT interface into fine granular small interfaces. If there is a change in small granular interface, only the classes implementing that interface  will be affected.</p>\n</li>\n<li><p><strong>Maintainability and Ease of use</strong>:  Since changes are limited to fine granular interface instead of generic FACT interface, code maintenance is easier. Unrelated code is no longer part of implementation classes.</p>\n</li>\n</ol>\n'}, {'answer_id': 56398042, 'author': 'Scott Hannen', 'author_id': 5101046, 'author_profile': 'https://Stackoverflow.com/users/5101046', 'pm_score': 2, 'selected': False, 'text': '<p><a href="https://drive.google.com/file/d/0BwhCYaYDn8EgOTViYjJhYzMtMzYxMC00MzFjLWJjMzYtOGJiMDc5N2JkYmJi/view" rel="nofollow noreferrer">Robert Martin\'s paper</a> on the subject gives an explanation that\'s mentioned less often:</p>\n<blockquote>\n<p>The backwards force applied by clients upon interfaces.</p>\n</blockquote>\n<p>If two classes depend directly on two different methods of a third class, it increases the likelihood that changes to either of the first two classes will affect the other.</p>\n<p>Suppose we have three classes: <code>Red</code>, <code>Green</code>, and <code>Blue</code>.</p>\n<p><code>Red</code> and <code>Green</code> both depend <code>Blue</code>, but each depends on a different method. That means that <code>Red</code> depends on one method of <code>Blue</code> but doesn\'t use the other method. Likewise, <code>Green</code> depends on <code>Blue</code>, but only uses one method, not the other.</p>\n<p>The violation of the principle is in <code>Red</code> and <code>Green</code> because each depends on a class - <code>Blue</code> - but <em>doesn\'t</em> use at least one of its methods.</p>\n<p>What problem does this potentially create?</p>\n<ul>\n<li>I need to change <code>Red</code>, and I also change <code>Blue</code> to accommodate the needs of <code>Red</code>.</li>\n<li>I haven\'t changed the specific method within <code>Blue</code> that <code>Green</code> depends on, but nonetheless, <code>Green</code> depends on <code>Blue</code> and I have changed <code>Blue</code>, which could still impact <code>Green</code>.</li>\n<li>Therefore, my changes to <code>Red</code> have the potential to impact <code>Blue</code> because they\'ve led me to change a class that both depend on.</li>\n</ul>\n<p>That\'s the &quot;backwards force.&quot; We sometimes change a class because of the needs of its clients. If that class has different clients that use it for different things, we risk impacting them.</p>\n<p>As stated, the simple definition of the Interface Segregation Principle is:</p>\n<blockquote>\n<p>no client should be forced to depend on methods it does not use.</p>\n</blockquote>\n<p>Between that and the above point from Robert Martin\'s paper, it\'s apparent that many explanations of the ISP are in fact talking about other principles.</p>\n<ul>\n<li>Classes or interfaces with lots of methods are undesirable, but not specifically because of the ISP. They might violate Single Responsibility. But the ISP violation is not in the big interface or big class - it\'s in the classes that <em>depend on</em> on the big interface if they don\'t use all of its methods. If they use all of the methods it still sounds messy, but that has nothing to do with the ISP.</li>\n<li>Classes that implement an interface but throw exceptions for certain methods are bad, but that\'s not the ISP, either. The ISP is about classes that <em>depend</em> on interfaces, not classes that <em>implement</em> interfaces.</li>\n</ul>\n<p>If we Google &quot;interface segregation&quot;, most of the top results that include code samples demonstrate classes that <em>don\'t fully implement</em> interfaces, which is not the point of the ISP. Some even incorrectly restate the principle:</p>\n<blockquote>\n<p>The Interface Segregation Principle states that clients should not be forced to implement interfaces they don\'t use</p>\n</blockquote>\n<p>...but that is <em>not</em> the principle. The defining paper mentions such concerns as a side-effect of violating the ISP, but indicates that they are Liskov Substitution violations.</p>\n<blockquote>\n<p>Moreover, each time a new interface is added to the base class, that interface must be\nimplemented (or allowed to default) in derived classes. Indeed, an associated practice is to add these interfaces to the base class as nil virtual functions rather than pure virtual functions; specifically so that derived classes are not burdened with the need to implement them. As we learned in the second article of this column, such a practice <em>violates the Liskov Substitution Principle (LSP), leading to maintenance and reusability problems.</em></p>\n</blockquote>\n<p>What\'s more, to say that a client should not implement methods it does not use doesn\'t even make sense. The <em>clients</em> of an interface do not implement the methods they use or do not use - they consume its methods. A client of <code>List&lt;E&gt;</code> does not <em>implement</em> the methods and properties of <code>List&lt;E&gt;</code>. It <em>calls</em> the methods and properties of <code>List&lt;E&gt;</code>.</p>\n<p>I don\'t mean to pompously cite the paper as if it\'s holy writ or something. But if we\'re going to use the name of the principle described in the article (the name of the article itself) then we should also consider the actual definition and explanation contained in that article.</p>\n'}]
['https://Stackoverflow.com/questions/58988', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/3012/']