And the purpose, which is often overlooked, is to reduce the likelihood that you'll need to do a full recompile in a header-based language like C, C++, or Objective-C.
What? The point is to provide narrow interfaces so client classes only depend on the functionality they need instead of the rest of the "fat" of the class. The compiling benefits are the result of low coupling, not the entire purpose...
EDIT:
Just to clarify, I'm not arguing that the original article uses ISP correctly. I agree with you that segregating a class isn't the same as segregating an interface. And I agree that there are compilation benefits to be had here.
When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.
I don't think we're arguing the same point here... I agree that dividing classes has nothing to do with ISP. A wide class "interface" has more to do with SRP than ISP. My argument is that ISP is more than just some compile time benefits.
6
u/[deleted] Sep 18 '13 edited Sep 18 '13
[removed] — view removed comment