Modularity requires more than being a "set of interconnecting components" (otherwise, all codebases with more than one source file would be "modular", and there

Modularity requires more than being a "set of interconnecting components" (otherwise, all codebases with more than one source file would be "modular", and there would be no monoliths). Modularity implies formalization and restrictions about how components communicate and depend. One of the goals: the ability to replace the implementation of one component without having to modify/adapt the others (the top-level component (also called 'main' or 'composition root') used to instantiate all the others doesn't count). If your components can be compiled separately (e.g without having to recompile the whole app), then you know you're modular (however, modularity doesn't necessarily involve dynamic linking). Real world examples of modularity: - device drivers of the Linux kernel - SDL device backends - decoders/demuxers in VLC - Cubase VST effects - Filters in DirectShow and Gstreamer Real world non-examples: - LLVM backends: in practice front-end implementations need to know about the various backends, so you can't simply add one. - GCC frontends: almost modular, however, there's some bunch of places you still need to modify so they know about your new frontend. - GCC plugins: although no line of code in GCC know about your plugin, your plugin can depend upon almost anything from the GCC implementation itself, in other words, the plugin API is too big (=the density of interconnections is too high). - Descent 1&2 (the game) enemies: the list of enemies appears at several places in the codebase, so you can't simply add one (=the density of interconnections is too high).