Where should I place my interface?

Question

I have an interface to communicate with a DB (actually it is not a database, but this is to give a concrete example):

interface DbInterface{
    Result sendQuery(Query q);
}

And I am trying to improve reusability by separating specific components into individual projects:

• App1, an application that requires access to a database
• App2, an application that requires access to a database
• DB1, a concrete implementation of DbInterface (let's say SQL)
• DB2, a concrete implementation of DbInterface (let's say using some NoSql database)

How do you typically design such an architecture and where should DbInterface be located?

• in one of the applications? but that means all other three component depend on that project to access the interface - does not sound right
• in one of the DB implementations? same - does not sound right.
• in both DB implementations? code duplication.
• in a separate project, which would only contain that interface? seems abusive to include a dependency for one interface only.

For reference, this is Java + maven, but the issue is fairly generic I suppose.

Answer 1

The interfaces are what you use to define a contract between the Applications and the implementation. That contract is usually managed by a middle project referred to as the API or SDK.

The application uses interfaces from the SDK, and the DB1 project implements those interfaces, but it's the SDK project that defines those interfaces.

Answer 2

I would personally go with the separate project. Pretty much every project I have worked on has had some kind of 'common' project/library that all others reference.

While it probably is overkill just for a single interface, it seems likely that there might similar cases in the future, and when that happens you already have a dedicated place to put them.

I don't know the ins and outs of your applications, but are there no helper classes etc that might be of benefit to both projects that could also go in a common project?

Answer 3

A separate project would be best in this scenario. Though now it will contain just a single interface, it may grow. Normally this type of project is called something like "API". There is no reason that a project such as this cannot contain some logic (for example, if you wanted to provide a facade on disparate API interfaces), but it should not be implementation specific.

Most applications should only have to rely on this API project as you should be coding to interfaces anyway. Only projects which tie in some sort of specific implementation will actually have to know about the API implementations. In modern applications that extensively use DI, the implementation is usually just a runtime concern.

Examples abound in the Java realm. JPA and Apache Commons Logging (or any other logging API) are a couple that you have probably already worked with.

As far as your comment "seems abusive to include a dependency for one interface only". I can see how this feels a bit awkward the first time you encounter it, but I would argue that it is more abusive to include dependencies you don't need in a project as you would be doing if you had to include the implementation to get only the interface.