In Java, what is the technical motivation for extracting all interfaces into a separate project?

Question

I've seen Java projects where the interfaces are all extracted into a separate project.

What is the motivation for that? Is it just organizational?

For instance, the atmosphere project does this. I've seen others.

I'm considering using it as an organizing principle on a project I'm running and would like to know what other benefits it may provide.

Answer 1

There exists one use-case: Java SPI, service provider interface . The interface(s) are provided separately, and (alternative) implementations come separately. By a manifest entry with interface name, using an interface one can find all/any provider of that interface. Xalan and Xerces XML implementations come to mind.

Also without SPI being able to provide several implementations, like a Test Driven Development prototype, may make sense.

Answer 2

Just to offer my 2 cents,

I'm currently working on a C# project that has a separate project holding all the interfaces. The project was named 'framework' and was part of a larger project comprising of 10+ implementations of interfaces from that framework project. My guess was (which is also later confirmed by my immediate superior) is that it fully separates implementations from design , something called loose coupling .

That way various projects that inherit from the framework project can be separately developed or swapped out independently. From a developer that's new to the project, it's easier for him/her to get acquainted with all the methods that are used in other projects in one central place. Adding new methods or removing old ones are all done in one project, and every other project that uses those interfaces have a strict 'contract' to follow. In essence it assists with maintaining the project in the long run.

It also makes it easier to create mockups of certain parts of the framework during testing, to isolate each class individually and test them for possible errors.

It assists in adhering to the interface segregation principle in which if a particular interface has for example only a 'save' method, but we need 'log' and 'read' for specific implementation classes, we can just create another interface that will inherit from the parent interface, all in the framework project, and no wade around in different projects to find the interface we want to add. I found this when researching on Interface Segregation Principle.