Modular Programming - Key Aspects

Key Aspects

With modular programming, concerns are separated such that modules perform logically discrete functions. No (or few) modules interact with other modules of the system; except in the sense that one module may use another module, to achieve its purpose. The desired module goal is to have no interaction between modules .

Each module (which can contain a number of separate processes) works independently to another module. Something that is best understood at the lowest module hierarchy, when no other module is used. At the highest module hierarchy confusingly, there may be several layers of used modules, before the module achieves its purpose.

When creating a modular system, instead of creating a monolithic application (where the smallest component is the whole), several smaller modules are built (and usually compiled) separately so that, when composed together, they construct the executable application program. A just in time compiler may perform some of this construction "on-the-fly" at run time.

This makes modular designed systems, if built correctly, far more reusable than a traditional monolithic design, since all (or many) of these modules may then be reused (without change) in other projects. This also facilitates the "breaking down" of projects (through "divide and conquer") into several smaller projects. Theoretically, a modularized software project will be more easily assembled by large teams, since no team members are creating the whole system, or even need to know about the system as a whole. They can focus just on the assigned smaller task (this, it is claimed, counters the key assumption of The Mythical Man Month – making it actually possible to add more developers to a late software project – without making it later still).