Organizing interfaces

Question

I am just reading Agile Principles, Patterns and Practices in C# by R. Martin and M. Martin and they suggest in their book, to keep all your interfaces in a separate project, eg. Interfaces.

As an example, if I have a Gui project, that contains all my custom Gui classes, I will keep their interfaces in the Interfaces project. Specifically I had a CustomButton class in Gui, I would keep the ICustomButton interface in Interfaces.

The advantage is, that any class that needs an ICustomButton does not need a reference to Gui itself, but only to the much lighter weight Interfaces project.

Also, should a class in the Gui project change and thus cause it to be rebuilt, only the projects directly referring to the CustomButton would need recompilation, whereas the ones referring to the ICustomButton may remain untouched.

I understand that concept, but see a problem:

Lets say I have this interface:

public interface ICustomButton
{
    void Animate(AnimatorStrategy strategy);
}

As you can see, it refers to AnimatorStrategy, which is a concrete class and therefore would sit in a different project, lets call it Animation. Now the interface project needs to refer to Animation. On the other hand, if Animation uses an interface defined in Interfaces, it needs to refer to it.

Cyclic dependency - "Here we come".

The only solution for this problem, that I see, is, that all methods defined in the interfaces take inputs that are themselves interfaces. Trying to implement this, will most likely have a domino effect though and quickly require an interface to be implemented even for the most basic classes.

I don't know if I would like to deal with this overhead in development.

Any suggestions?

Answer 1

Beware of always, ever, and never - especially near all, none, or every.

Should you always put all of you interfaces in a separate assembly? No - not necessarily.

Should you put interfaces that you expect external consumers of your code to implement - possibly. I would put interfaces into an external assembly if you expect multiple assemblies in your project to rely on them - this can help break coupling dependencies. I've also used this practice to solve circular referencing issues, where assemblies need to be aware of interfaces in one another.

I don't put interfaces that are only used internally in a project in a separate assembly. I also don't promote interfaces into their own assembly when my projects are relatively small - or the interfaces are not intended to be used without the assembly that depends on them.

As for the example you presented - I would suggest that you consider NOT referencing classes in your system from interfaces. Whenever possible, I try to have interfaces only reference other interfaces - this keeps things relatively decoupled. You can't always achieve this - and so when you have these types of interfaces - you have to keep them with the assembly they depend on.

If you do decide to put interfaces into a separate assembly - you shouldn't necessarily put them all into a single assembly. You may want to break them out by their intended usage - this way consumers can pull in just the interfaces that are relevant to a particular domain of functionality.