Would one Method per Interface be a Reasonable Design Choice?

Question

Does it make sense to have interfaces like IAddable, IRemovable, IIndexable, to support each operation or would this sort of approach ultimately lead to unmanageable code?

Answer 1

Imagine you want to implement a sort-of NumberBucket that is like a collection for numbers.

You could create a somewhat fat interface like this one:

public interface INumberBucket
{
    void Add(int number);
    void Remove(int number);
}

And you could implement it with no problems:

 public class NumberBucket : INumberBucket
{
    public void Add(int number)
    {
        Console.WriteLine($"Adding {number}");
    }

    public void Remove(int number)
    {
        Console.WriteLine($"Removing {number}");
    }
}

But then later on you decide you need to implement a ReadonlyNumberBucket where numbers cannot be removed:

public class ReadonlyNumberBucket : INumberBucket
{
    public void Add(int number)
    {
        Console.WriteLine($"Adding {number}");
    }

    public void Remove(int number)
    {
        throw new NotImplementedException();
    }
}

Well, now there is no logical implementation for Remove so you have have to make it a no-op or make it throw. This violates the Liskov Substitution Principle.

Had you decalred two focused interfaces: IAddable and IRemovable you could have just not implemented IRemovable. This is the basis for the Interface Segregation Principle.

So, to answer your question: yes - it is reasonable but it may be a while before you see a return on your investment however. And just like @PhilipStuyck wrote in the comments:

[..] The question is if this example is applicable in your situation. The very first interface in this answer might be good enough for you and splitting it might be overdesign. Overdesign is also a code smell. You gotta know when to apply which pattern. Based on the short explanation in the question I cannot tell.

Answer 2

It depends on level of a "control" you have in your application design. If you have items that may be "Addable" but not "Devidable", what you say makes pretty much sense.

But if in your app domain, all items usually support basic operations you describe, don't see a reason to move them into the separate interfaces.

Answer 3

I saw some comments about the fact that the Liskov substitution might be broken if you let all methods inside an interface. To be honest, even Microsoft violates the Liskov substitution principle sometimes. For example, they made the Array to implement IList even that some methods on this interface are not supported by the Array type (for example if you cast an array to IList, the "Add" method throws an exception of type NotSupportedException).

The MOST important thing is this: Do you see any logical relation between your methods ? at least they must belong to a certain category or something. if so, group them together into an interface. In your case, IAddable and IRemovable seem for me that are somehow corelated because they both represent something simmilar: an object can be MOVED (added or removed) from some basket. The IIndexable for me seems like a "bonus" like something that you can add but is not mandatory. So if I would be your architect I would put IIndexable methods in a separate interface.

Anyway if in a far future an object would be "addable" but will not support "remove" then you could easelly solve this problem by splitting your interface in two and make our old interface to inherit them both : IAddable, IRemovable. I tend to "segregate" interfaces at the right moment, i don't like splitting my interfaces from the very start of my architecture.

So, remember:

• In the beginning, segregate only what's obvious then segregate when the situation requires a segregation or even you can choose for the sake of readability / framework understanding to NOT segregate (as microsoft did because for them, an array is a kind of List and this should remain like so).

• Patterns and principles like SOLID are just a very powerfull guideance but rules are made sometimes to be broken. Keep this in mind.