Interface Segregation Principle

This is another principle developed by Robert Martin who I have had the great pleasure to see speak several times at conferences.  He is a very lively speaker and you return to coding wanting to do your best work after you see him speak.  As for a skilled software craftsman, he is at the top of his game. 

ISP says that no client should be forced to depend on methods it doesn't use.  Martin came up with this when he was consulting with Xerox.  He found they had a job class that was used for every single task in the system.   A stapling job shouldn't have to know anything about a print job and all the methods for printing.

OK people I work for Xerox and there nothing called  Staple Job.  Stapling is an attribute on a job.  Print jobs can have an attribute that says staple me.  But so can Copy jobs.  So I'm not sure where he saw this but maybe it was a looong time ago. 

In practice when working with Microsoft Windows for example, there are what I call "Big A!& Classes".  They are huge with a bazillion attributes and methods.  Often I don't care about 9/10ths of them. I search through the documentation for what I need.  This is one of many interfaces I have used and dare say I have created that violate this principle. 

However, when I create an interface, I literally fight people to the bone to keep it simple.  More functionality is desired and interfaces get new methods and before you know it, you have a massive class with more methods and data then any sane person can keep straight.  I have to argue quite a bit to keep it simple - deadlines are tight and people don't want to do the extra work for this principle. 

On the flip side, I think this principle could be considered "too pure" for many software engineers.  And engineers I talk to about this principle find it too difficult to practice in a real word setting.  They understand it intellectually but don't see the benefits.   Testing is one huge benefit.  If you have a massive class for a job you would have to implement the print functions even for a staple job (which doesn't exist, just saying…).  Even if it was a no-op, you'd have to test it.

Testing takes up over half of our development activities.  So if you can save on that, ISP is worth it!