+972 52-548-6969
Limiting your abstractions: Reflections on the Interface Segregation Principle
I have found two definitions for ISP (in this post, I assume that you know what ISP is, if you don’t, look at the links below).
This one I can fully agree with:
Clients should not be forced to depend upon interfaces that they don't use.
And this one I strongly disagree with:
Many client specific interfaces are better than one general purpose interface
For fun, both of those links are from Object Mentor.
It would be more accurate to say that I don’t so much disagree with the intent of the second statement, but that I disagree with the wording. One (literal) way of understanding the second statement is to say that we want specific interfaces over generic ones. And I would strongly disagree. An interface is an abstraction (for the most part), and I want to reduce the amount that I have in my system.
Let us look at an example, based on my recent posts in this series.
![image_thumb[3]_thumb](http://ayende.com/blog/Images/Windows-Live-Writer/Reflections-on-the-Interface-Segregation_388F/image_thumb%5B3%5D_thumb_2.png "image_thumb[3]_thumb")
In my previous post, I said that I want to remove both CargoWasHandled and CargoWasMisdirected in favor of IHappenOnCargoInspection. But what about the two other methods?
Would ISP force me to have IHappenOnEventRegistrationAttempt and IHappenOnCargoHandling?
Sure, those are many specific interfaces, but are they really better than something like IHappenOn<T>? Is there something truly meaningful that gets lost when we have the generic interface?
I would say that this isn’t the case, further more, I would actually state that having a single interface will lead to more maintainable code, because there are less abstractions in the code. There is a codebase that is more cohesive and easier to understand.
But I’ll talk more about cohesion on my next post.
Comments
No comments postable on this post? It's like 3 days it seems to accept comments, but they never show up :-\
Sorry, 2 days
I generally agree. Had this argument before during code reviews, the reviewer argued that generic interfaces made the code much harder to navigate with things like Go To Definition / Inheritor. He had a point, but I'm still not convinced.
I do not see how you disagree with the second definition. You do have many client specific interfaces: IHappenOn<Cargo> & IHappenOn<HandlingEvent>! You just used an "type macro"/"type abstractio" to make them uniform and easier to understand. IApplicationEvents is a general purpose interface, while IHappenOn<Cargo> is a role interface. IHappenOn<T> is just an abstraction of the roles.
Hopefully with angle brackets:
I do not see how you disagree with the second definition. You do have many client specific interfaces: IHappenOn>Cargo< & IHappenOn>HandlingEvent<! You just used an "type macro"/"type abstraction" to make them uniform and easier to understand. IApplicationEvents is a general purpose interface, while IHappenOn>Cargo< is a role interface. IHappenOn>T< is just an abstraction of the roles.
Comment preview