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):
DataReaderDataWriter
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
common/data/DataReadercommon/data/DataWriter
- Separate like
userapp/data/DataReaderserverapp/data/DataWriter
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 tocommon.aor - 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?
Keep them together: any format changes will require editing them together, and unit testing the format is easiest done using your existing reader & writer code together.
However, just because the source files are stored together, doesn’t mean they have to compile compile together. You could set it up so that (UNIX filename conventions for illustration only):
userapp depends on libreader.a depends on DataReader.o
while
serverapp depends on libwriter.a depends on DataWriter.o
and then there’s no reason to build libwriter at all when you’re only compiling the client.
3