Splitting a C ++ application into libraries

Question

My C ++ project is growing. We are also moving on to using cmake to create now. I want to split the application into libraries so that they can be linked for testing, preparing the application package, etc. Now I would split my code into libraries as follows:

• core
• GUI
• (they are used by the kernel and other components)
• io (xml parsing / output using class printing functions in the kernel)
• tests (unit tests)
• simulator (tests the core)

An alternative would be a partition based on the directory structure - one library for each directory. But from my past experience, this leads to too many libraries, and then the library dependency becomes difficult to process at build time.

Are there any best practices in this regard?

Answer 1

Sit with a sheet of paper and decide your library architecture.

A library should be designed as a set of levels.

• A library at level A (basic) should have dependencies only on system libraries and only if it should be in libraries at level A.
• A library at level B may have dependencies on libraries at level A and system libararies, and only if it should be in libraries at level B.
• etc.

Each library should present complete work at a certain level. Things at a lower level usually have smaller jobs, but there are many. A library at a higher level should present the complete task. those. do not have lib for windows objects and lib for events. At this level, manual interaction with the window is set here (this includes interaction with events).

It seems you have identified some resonant functional groups. The only thing a little suspicious is io. If you really have common IO routines that provide real functionality. But if this is just an IO grouping for a bunch of different objects, then I would refuse it (it all depends on usage).

So, the next step is to determine the relationship between them.

Regarding the use of directory structures. Usually everything in one directory will be present in the same library, but this does not exclude the possibility of displaying other directories. I would not put half of the classes in a directory in libA, and the other half of classes in libB, etc.

Answer 2

You should familiarize yourself with the large-scale C ++ software from John Lakos.

You may not be able to read it before you begin, but you should put this book on your list.

Otherwise, Martin Yorke's advice sounds.

One more thing, although I would recommend building a tool like doxygen that can give you dependency diagrams of your code base. If you are trying to do this type of restructuring, you should get rid of the circular dependencies between your libraries. Lakos describes many ways to reduce dependencies - some obvious, and even less so.

Answer 3

I like to start with a package diagram, which has only one way arrows.

http://www.agilemodeling.com/style/packageDiagram.htm

Your list looks like a good start.

Answer 4

Seems reasonable.

I would request what your unit_tests library should do. Given the collection of “projects” creating libA, libB, libC ... I expect to see some relevant testA projects testB testC (regardless of whether they build libraries or executable files, it depends on whether the built-in tests run autonomously or are loaded into which or test runner).

I also have a little fear of the utilities libraries. They seem to have an amazing ability to inflict pain and suffering in the long run. For example, perhaps your IO library has no dependency other than a utility library. One day you will want to reuse the IO library in another project on another platform. The only problem is that now you will also need to port the entire utility library (90% of which IO is not used) or reveal 10% of them on which the IO depends. Sometimes it is better that the libraries are slightly more dependent, due to some duplication of code.