Question

I have a reservation system that allows you to Book a reservation, Modify an existing reservation, and Cancel an existing Reservation. I was looking into the Interface Segregation Principle and I was wondering how thin I should make my interfaces and if I am violation the Single Responsibility Princple. My intial design was:

interface IReservation
{
     void Book();
     void Modify();
     void Cancel(); 
}

but then I thought, what if one Reservation system, does not need to implement one of these methods for a reservation and is just concerned with Bookings for example, so I did the following:

interface IBook
{
     void Book();
}


interface IModify
{
    void Modify();
}

interface ICancel
{
    void Cancel();
}

Now I can do something like this:

interface IReservation : IBooking
{


}

or

interface IReservation : IBooking, IModify
{


}

So the question becomes am I taking it to far with thinning it out like this. Also, it becomes harder to think of names for the interface, for example, I don’t like IModify or ICancel (They just seem like methods to me that should be on the IReservation interface). How do you determine what should go into an interface and what should be segegrated out into another interface, class, etc…

Answer 1

You have two things you have to consider when looking at the scope of your interfaces:

1. Does it make sense to require every IReservation to implement these members?
2. Does it make sense to reference member X without member Y?

The first is what you’ve covered, and have arrived at a conclusion of “No”. The second, though is just as important. Does it make sense to think of something as “can modify” without it being able to do anything else? If not, consider making IReservation and IModifiableReservation, or some other grouping of functionality.

For example, it seems like Cancel and Modify go hand-in-hand, so might want to put them both together on the IModifiableReservation, then have your class implement that interface.

As you have it, that seems a little too granular.