27

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.

mtyson
  • 8,196
  • 16
  • 66
  • 106
  • 3
    It makes dependencies easier to handle and avoids "accidentally" using implementation classes not meant to be seen. – biziclop Apr 13 '15 at 13:09
  • 4
    I guess one has to differentiate: just throwing any interface into a special "interface" project doesn't feel right. But to carefully define your components to avoid cyclic dependencies and improve clear boundaries is normally a good thing. – GhostCat Apr 13 '15 at 13:15
  • Related: http://stackoverflow.com/questions/1004980/should-interfaces-be-placed-in-a-separate-package – Maroun Apr 13 '15 at 13:19
  • 1
    You can import the API with `compile` dependency and the implementation code with `runtime` dependency. This means that you are **always** only compiling against the public API. This is essentially emulating what the, for example, JavaEE APIs have been doing for a very long time. – Boris the Spider Apr 13 '15 at 15:11
  • The standard Java library does not do this for most of its interfaces. – Raedwald Apr 15 '15 at 18:47

2 Answers2

14

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.

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
6

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.

matrixanomaly
  • 6,627
  • 2
  • 35
  • 58