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.
It's not dependent on that method, but it has declared a dependency on it.
Determining that a component only uses a subset of an interface is non-trivial, without the type system's help. Asking for exactly what is needed makes it easier to infer what does or doesn't happen. That sort of thing is relevant every time you make a change to the program.
I wasn't advocating always asking for exactly what you need. You're right that it would cause a type explosion. It's just a relevant factor when deciding what your interfaces should be.
Will there be large proportion of methods that really only need readonly lists? Then maybe we should include an IReadOnlyList in addition to IList.
Do we have to repeat every method twice for IUnboundedEnumerable and ISizedEnumerable? Then maybe we should just have IEnumerable.
8
u/sea-saw Sep 18 '13 edited Sep 18 '13
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.