Sharing classes or interfaces between different projects

Question

I was looking for some answers in SO or here, but without any results, that's why I would ask you.

Let's assume I have a two different projects - for example server part and client part of an app. I'm developing my own part, while my friend is making the second one. But both of us should use some common interfaces like User or AccountInfo or ChangableAccount... whatever in order to ensure a compatibility. For example if a clients send a User data to server, then the server should operate on the same class. The same with interfaces etc. Moreover, if there are any changes in a common interface, both projects should adjust its code to the new situation.

The only solution I can see now is, to create a one extra project in which all common things are defined. We, me and my friend, should add this project as a dependency to a main project (client or server). Shared project can be managed by some version control system, so we have always the most up-to-date state.

What other solution would you suggest? How such problems are solved in professional apps?

Answer 1

create a one extra project in which all common things are defined

This is the exactly first step to share reusable parts - and its the easy part. The more challenging part is to decide if the two projects which are using the shared library shall have independent release cycles (or not), and if it should be possible that "project A" uses version 1.0 of your shared lib, whilst project B uses version 2.0 at the same time.

If you want the latter to be possible, you need to have a strict versioning scheme and release management for your library (and version numbers as part of the library file name, like suggested by @RoryHunter). You should also take care about backward compatibility in your lib in this situation. Your library should be managed as a separate product, adding unit tests to it to make sure the different versions in production will be a good idea, and a tool like Maven can make sense, too.

If, however, you want prevent that situation, you should manage "project A", "project B" and your lib as a common project, with a combined development, build and release process. This will allow to change the common interface of the shared library much more and often than in the first scenario. And you won't need something like Maven or version numbers in the library file name. But the tradeoff is that A and B cannot be developed independently any more.

Answer 2

Your solution is the right one. Put the shared code into a another project that builds its own JAR file, and use it in both projects. When building the JAR file, you may want to include the version in the name, e.g. in Debian style;

libmyproject-shared-1.0.jar

It doesn't prevent versioning trouble, but it should help. I've never used Maven, but I understand it can help in this situation.

Answer 3

create a one extra project in which all common things are defined

That's exactly the way that .Net expects you to do it.

Abstract these objects into a third Assembly, and reference this from both projects. I'd suggest doing so as Interfaces, which is cleaner, but ...

Watch out for Serialisation:

• The only way I could directly serialise/ deserialise objects between the two programs (admittedly this was a while ago using Framework 2.0) was to install the "shared" assembly into the Global Assembly Cache on both client and server machines. If the assembly was "local" to each project, then the Framework saw them as discrete Types and refused to [de]serialise the one into the other.
• And [de]serialising objects Typed as Interfaces is a bit of a "challenge". The original, non-Interface Type didn't seem to "make it" through the Serialisation "pipe" so the receiver didn't know what concrete Type to "build" from the incoming stream.

Answer 4

As others have suggested, your thought process is accurate. Professionally, most would use something like Maven or Gradle to manage these dependencies efficiently.