Interfaces between multiple projects

interfacesopen-closeproject-structure

I'm slightly confused over the following:

ProjectA 
-------- GetUsers (Implements IDBConnector)
-------- IGetUsers
-------- UserModel

ProjectB 
-------- Main

I have two projects one main project (project B) and another which gets data from a database (project A). Project A has an interface which the main class makes use of. The GetUsers class is then injected within the main class of type IGetUsers.

This means there is a dependency of Project A for Project B as Project B needs to know how the interface is defined and the class definition itself. I am fine with this from a code standpoint but I can't help thinking that the interface should be kept somewhere else as it is essentially a contract and I am trying to follow the open/closed principle i.e. I shouldn't have to touch the main class to change how the database interaction is dealt with. In my example however if I remove Project A I lose the interface definition and I would have to modify the Main class.

I would have thought that Project B would be a good place to keep the interface but this would result in a circular reference as Project A would need to reference Project A for the interface declaration and vice versa for the class implementation.

The other option is to have a separate project for interfaces which I have seen mentioned in this question:

Sharing classes or interfaces between different projects

But to me this seems a little silly to have this example interface in a whole separate project while there is only one interface at current.

Best Answer

You almost have you answer here:

I would have thought that Project B would be a good place to keep the interface but this would result in a circular reference ...

Following the Dependency Inversion Principle, interfaces should be defined by user, not the implementer. As you said in your question, the interface is essentially a contract; in order to invert the dependency, the user has to define the contract, so that the implementer depends on it. This contrasts with the normal flow of dependency, where the user depends on the contract that is forced on it by the implementation.

So, back to organizing the separate projects: If B is the user of the IGetUsers interface, then it must be the one to define it. If A provides an implementation of that interface, then it must depend on B. And now, not only to avoid circular references, but also to free B from any future dependencies that the may come, you can define a third project, C, which has the sole responsibility of composing the system out of the small modular pieces.

This concept is known as composition root, and is ideally the place where all dependency injection should live, leaving A and B outside the bounds of a dependency injection framework, if one were to use it.

Related Solutions

Java – Who Extends Interfaces and Why?

In the case of generic type variables the compiler doesn't actually care if T is a class, an interface, an enum or an annotation. All it cares about is that it is a type with a given set of sub- and super-types.

And there is no reason to complicate the syntax just because in one other place (where you actually implement an interface) the distinction between classes and interfaces is relevant (for example if you implement an interface, you need to implement all methods it defines, but you don't need to, if you extend a (non-abstract) class).

Assuming for a moment that you'd have to write implements here, then you'd also need a separate syntax for enum values (instead of simply writing <E extends Enum<E>>) and annotations (which you can easily declare using <A extends Annotation>).

The only place where you need to write implements is at the point where you actually implement the interface. At that point (and that point only) the difference is important, because you must implement the methods defined in the interface. For everyone else, it doesn't matter if any given A is a base class or an implemented interface of B: it's a super-type and that's all that matters.

Also note that there's one other place where you use extends with interfaces:

interface A {
}

interface B extends A {
}

At this point implements would be wrong, because B does not implement A.

Java – Separating java projects

I'm going to take a quick first cut at this (great Q BTW!):

Would imposing a structure on the large project (i.e. into smaller sub-projects) slow the compiler down?

Not by enough that it matters, the overhead is actually in Maven invocations.

Also, I have a slight concern on what impact this might have editing time in IDEs (we principally use Intellij). Intellij seems to build each project in turn through the dependency tree - i.e. if C depends on B depends on A, and I change A, it won't try to build B unless A compiles, and so on. Arguably that's advantageous, but I have found that if - for example, I change an interface in A that is widely used in B and C, it takes some time to fix all the errors from that change...

Different IDEs have their different strengths with regards to Maven bindings and dependency management. The current state of play seems to be that it mostly just works on the latest Eclipse, Netbeans and IntelliJ - but you will have to teach your developers the emergency double whammy of "Refresh source files from disk and rebuild all related maven projects".

I find I'm having to do that less and less these days though. Having an SSD drive makes a massive difference here BTW.

snip factory classes paragraphs

Dependency management is incredibly important, regardless of what technology (Maven/Ivy/whatever) use use to help you implement it.

I'd start by getting the extensive reporting out of the Maven dependency plugin and take stock of what you've got. Generally speaking you set the dependency in the dependency management of the POM as high up the food chain as possible, but no higher. So if two of your submodules use an external dependency, then haul that into their parent POM and so on and so forth.

Upgrading external JARs should always be done as a proper mini-project. Evaluate why you're upgrading, alter source code to take advantage of any new features/bug fixes etc. Just bumping the version without this analysis and work will get you into trouble.

So, in general, my questions are:

Does anyone have any experience of breaking up large projects? Are there any >tips/tricks that you would be willing to share?

Interfaces and Dependency injection are your friend.
Michael Feather's book on dealing effectively with legacy code is a must read.
Integration tests are your friend
Splitting the sub projects into foo-api (interfaces only!) and foo-core and having modules only depend on the foo-api helps a great deal and enforces separation
Jboss Modules and/or OSGi can help enforce clean separation

What impact did this have on your development and build times?

Very minor impact on dev and build times - a massive gain in time for our overall continuous delivery pipeline.

What advice could you offer on structuring such a break-up of such a project?

Do the little things right and the big things tend to fall out cleanly afterwards. So split things off bit by bit - don't do a massive restructure of the whole lot unless you've got a high percentage of coverage with your integration tests.

Write integration tests before the split - you should more or less get the same result(s) after the split.

Draw diagrams of the modularity you have now and where you want to get to. Design intermediate steps.

Don't give up - some Yak shaving now builds the foundation for being able to "rapidly build and refactor without fear" Shameless plug -> from Ben and I's The Well-Grounded Java Developer.

Best of luck!

Best Answer

Related Solutions

Java – Who Extends Interfaces and Why?

Java – Separating java projects

Related Topic