Our project consists of user application and server application. The server application prepares data files that the user application consumes. Because the data is huge, it is stored in custom format. So the project includes many classes related to reading and writing the data. The user application does not need the writing side, so we don't want to have the code there both because it might run on resource-limited devices and because it prolongs compilation (C++ is not known for having fast compilers).
So say I have two classes (I have tens of such pairs):
These classes both operate on the same thing, the serialized data. But the first is only needed in the user application and the second is only needed in the server application. Would you suggest keeping such classes
- Together; in say
- Separate like
With this goes the compilation. The common stuff lives in
common and is compiled into a library linked to both. So the first option further splits into two:
- Together in
common/dataand linked to
- Together in
common/datadirectory, but each linked to the target that needs it.
Now each has it's advantages and disadvantages:
- They are closely related, so it makes sense to keep them together. But
- having both in one library makes that library larger and compile longer
- compiling each separately means directory layout does not correspond to project layout, which is rather confusing and complicates the build scripts
- Keeping them separate makes the build structure more logical and avoids unnecessary work for the compiler, but when updating them, components far apart need to be modified (both applications are maintained by the same team, so it's not like someone wouldn't be aware of the other part)
We currently have mixture between the approaches (some classes are separate, others not and the common library contains a lot of stuff that should be in the individual projects), which I would like to clean up.
Is there any usual recommendation for such situation? Or some useful experience with similar cases?