How do you carry out modularized development in c/c++?

Question

I can deal with only the easiest case, when there are only 2 modules A and B

A is dependant on B, so I build B as a library and include B's header file in A, also link to B library when building A.

This won't work when A and B are inter-dependant, and even worse when the number of modules grow ..

So what's the general way to carry out modularized development in c/c++?

UPDATE

Sorry, seems my title is inacurate, the rephrased version is: how can I divide a module into many .h and .cpp files(not a single one)?

Answer 1

If A and B are inter-dependant, you can't deploy any of them in isolation. Therefore you practically have a single module, not two. (You can refactor your modules to extract the common stuff into a third module C though, thus making both A and B depend on C but not on each other.)

A well designed project shall not contain cyclical module dependencies. This guarantees that there is always a sane build order between its modules.

Update

how can I divide a module into many .h and .cpp files(not a single one)?

The basic principle is pretty similar to that of the module level: avoid cyclic dependencies and duplicate definitions. @Felix already mentioned the essential tools for this: forward declarations and include guards. I can also second @kotlinski's recommendation of the Larman book for a deeper understanding of the topic.

Learning good design takes practice, so don't give up if your first approach doesn't look perfect :-) In C++, one particular pain is excessive recompilation after changes. To minimize this, strive to ensure that the things (classes, headers) you depend on the most are the ones which change the least frequently. I.e. depend on interfaces (abstract classes), not concrete implementations.

Also, strive to keep a healthy relationship between the logical partitioning (classes/components) and the physical partitioning (header/cpp files). The typical way is to put every class definition into a separate header file, and its implementation (if applicable) to a separate cpp file. However, you may prefer defining tightly coupled classes (components) in a single header, to emphasize their logical relationship.

Answer 2

Generally speaking, having two interdependent modules is a design smell. You can either

1) merge the modules into a new one C, or

2) extract a common subset into I, making A and B depend on I but not each other.

update

Use forward declarations and #pragma once or #include/#ifndef protection:

http://stackoverflow.com/questions/553682/when-to-use-forward-declaration

http://stackoverflow.com/questions/1804486/should-i-use-include-in-headers

Answer 3

The solution is to make sure your modules form a directed acyclic graph... I.e. if A depends on B, make sure B doesn't depend on A. It takes a lot of discipline but is worth it in the long run.

If you are interested in this stuff, Large Scale C++ Software Design is a good read.

Answer 4

Design Patterns, for example Model–View–Controller - MVC.

Model–View–Controller (MVC) is a software architecture,1 currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from input and presentation (UI), permitting independent development, testing and maintenance of each.