Why should you strive for more than one interface member whenever possible?

Question

In general, why should you strive for three to five members per interface?

And then, what's wrong with something like this?

interface IRetrieveClient
{
    Client Execute(string clientId);
}

interface ISaveClient
{
    bool Execute(Client client);
}

interface IDeleteClient
{
    bool Execute(string clientId);
}

When I see the this, it screams "Antipattern!" because the interface isn't accomplishing anything, especially when the designer of the application intends for each interface to have a one-to-one relationship with the class that implements it.

Read: Once an interface is implemented, it is never reimplemented again. Now, I didn't design this system and it seems to me like what they wanted to do was implement some version of the command pattern, but when speaking to the developers, they don't seem to get it.

Answer 1

This looks entirely reasonable to me. I'm perfectly happy to have a small number of methods (or indeed one method) per interface.

Note that the benefit of combining interfaces is that you can (say) selectively present different views of a class by casting appropriately. e.g. you can construct/modify a class and then present it (narrow it) via a more restricted interface (e.g. having a read-only interface)

e.g.

interface Readable {
   Entity get();
}

interface Writeable {
   void set(Entity e);
}

A class can implement both interfaces such that you can mutate it, and then you can present it to clients simply as a Readable object, such that they can't mutate it. This is possible due to subdividing the interfaces.

Answer 2

You should be careful to use general rules and apply them too strictly. There is nothing wrong with your approach per se, if that is what you need.

But you might want to think of the following alternative:

interface IClient
{
     Client Retrieve(string clientId);
     bool Save(Client client);
     bool Delete(string clientId);
}

The advantage of this approach is that when you use injection, you only have to register one instance, and you only have one interface in your constructor.

So if it logically belongs together, I would keep it in one interface, because it reduces cluttering and is less complex.

Answer 3

One area where I've used the single-method-per-interface pattern quite extensively is with generics together with some generic dispatch infrastructure.

For example:

public interface IValidateEntities<T>
{
    bool Validate(T entity);
}

Then when it is necessary to do something with an entity of some type, we can use reflection to find out which implementation to invoke (results of reflection usually cached in advance).

I gave a presentation on this pattern a while back and it's available for viewing here:

http://www.infoq.com/presentations/Making-Roles-Explicit-Udi-Dahan

Answer 4

The important thing in the design is to keep to what Robert Martin calls single responsibility principle. In your case I think what L-Three proposed is quite reasonable as client will have one responsibility - talk to database (or service, e.t.c.). So if you see that methods in IClient will become totally different for some reason and are breaking SRP then you can split it many interfaces and I don't think if an interface has only one method it's a problem. For instance a good example is an interface called IKeyGenerator that generates keys in a thread safe manner. That interface has just GetNextKey() method which is perfectly enough.