Why is recompilation of dependent code considered bad design?

Question

I am reading a book C++ Software Design by Klaus Iglberger. In the book, the author asserts multiple times that recompilation effects of dependent code is extremely bad. For example,

The heart of the problem is the direct dependency of all shape classes and functions on the enumeration. Any change to the enumeration results in a ripple effect that requires the dependent files to be recompiled.

Can someone explain why this recompilation of dependent code is considered very bad? I completely understand that dependencies will cause issues, but that aside, why the specific focus on recompilation effects?

Edit:

More context around the quote.

Note that this addition (addition of new enumeration value) would have an impact not only on the switch statement in the drawAllShapes() function (it is now truly incomplete), but also on all classes derived from Shape (Circle and Square). These classes depend on the enumeration since they depend on the Shape base class and also use the enumeration directly. Therefore, changing the enumeration would result in a recompilation of all your source files.

Answer 1

Recompiling dependent code is expensive: compiling takes time, particularly in a language as syntactically complex as C++. Historically, for most C++ compilers it was extremely expensive. But more importantly, dependent code might not be under your control. Changes that require recompilation mean that codebases around the world require recompiling when they update your library. This makes upgrading much more difficult than it would be if your new version were binary-compatible.

Answer 2

Not only is recompiling dependent code expensive - right now it might be manageable, but software tends to grow, and when you have millions of lines of code to recompile just due to a little enum getting a new member, you have a problem.

Also, whenever you recompile, there is a chance that this doesn't work - you may want to make a change in the class causing the recompile, and then after a few minutes of compilation there is some compile-time error. Now you have to either change the change, or change something in the dependent class, or rollback everything. You don't need that complexity in your daily life.

Finally, from a high-level design perspective, having avoidable dependencies is a code smell and points to chances to improve your class (module, package, ...) design. A good practice is "high cohesion, low coupling".

High cohesion

A class that has high cohesion takes care of as little responsibilities as possible/useful. This means that the responsibilities of a class do not explode over time and it is always very clear which class is responsible for a given task. Failing to do this leads to a class design with relatively few, huge classes. Maybe not so relevant for your current question, but something to keep in mind.

Low coupling

Any two classes should have as few dependencies on each other as possible. Ideally, changing a class should have little or no effect (recompilation, revalidation, chances to break something, etc.) on any other class, or at least as few as possible. This opens up many good results; for example it becomes much easier to write good tests, you can make changes with much better confidence, and often it is just simpler (less time spent coding); especially for newcomers to the code-base. Good class design, and patterns like dependency injection can help here. Not having to compile another class is a good sign that there is low coupling.

Answer 3

First, recompilation isn't as bad as he makes it out to be. Compilers are fast. How often are you going to change that enum?

Second, you figure out what forces recompilations and avoid that kind of dependency, if the compilation time gets annoying. This enum would likely be invisible to anyone outside his "shape" classes, or can be made invisible. Obviously if you can rearrange things to avoid recompilation, then do it.

Third, having dependency upon dependency upon dependency is by itself not clever. If class C can log things, then class B using class C shouldn't be affected by this logging, nor should class A using class B. Recompilation is just a symptom in this case.