Ayende @ Rahien

Hi!
My name is Ayende Rahien
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

@

Posts: 5,947 | Comments: 44,541

filter by tags archive

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

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

njy
njy

No comments postable on this post? It's like 3 days it seems to accept comments, but they never show up :-\

njy
njy

Sorry, 2 days

Neil Mosafi

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.

Daniel Martin

I do not see how you disagree with the second definition. You do have many client specific interfaces: IHappenOn & IHappenOn! You just used an "type macro"/"type abstractio" to make them uniform and easier to understand. IApplicationEvents is a general purpose interface, while IHappenOn is a role interface. IHappenOn is just an abstraction of the roles.

Daniel Martin

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

Comments have been closed on this topic.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. RavenDB Sharding (3):
    22 May 2015 - Adding a new shard to an existing cluster, splitting the shard
  2. The RavenDB Comic Strip (2):
    20 May 2015 - Part II – a team in trouble!
  3. Challenge (45):
    28 Apr 2015 - What is the meaning of this change?
  4. Interview question (2):
    30 Mar 2015 - fix the index
  5. Excerpts from the RavenDB Performance team report (20):
    20 Feb 2015 - Optimizing Compare – The circle of life (a post-mortem)
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats