Modular programming is a programming paradigm. The approach is to systematically split computer programs into logical subblocks called modules. It breaks down a large application into modules, groups of functions, methods and processing, so that it can develop and improve them independently, and then reuse them in other applications. The development of the module code can be attributed to different (groups of) people, who perform their unit tests independently. Virtually all current imperative programming languages allow the implementation of the modular approach.
This method of bundling allows encapsulation comparable in some respects to that of object programming and allows the organization of the source code into logical work units. The modules also define useful namespaces when using them. Modular programming does not involve the use of a particular style of or programming paradigm; The elements it structure can be object style, imperative or functional. The opposite of modular programming is refinement.
Modular programming is intended to keep larger software projects controllable and clear. Modules can be individually planned, programmed and tested. Universal modules only need to be programmed once and can be reused. In this respect, there is a similarity to the service-oriented architecture (SOA). When all modules are successfully tested, these items can be logically linked together and assembled into a larger application. Only then will the application be ready for use as a whole. With modular programming, the procedural approach has been extended by merging procedures with data into logical units. Classes are modules and basic elements in object-oriented programming. Modula-2, Ada, Oberon, Component Pascal and VHDL are typical modular programming languages. In other programming languages, libraries are available that can mimic the modularization of the programming language if it is not supported by the language. In particular, this is useful if the language offers the possibility to load additional classes at runtime. This is done in Java using the OSGi Framework. In .NET, too, there are ways to dynamically reload assemblies.
This style of programming greatly facilitates incremental improvement, re-usability and code sharing, and is particularly useful for building libraries. Also, according to the programming languages, the modules can be set up, which brings modularity whose flexibility multiplied then leads to talk of generativeness. Generic programming is an over-all that can benefit from the modularity provided by modular programming.
The module as a component
Components are often perceived in terms of black boxes/white boxes. A component is seen as a black box when one is only interested in its use and behaviour, defined for example by specifications. A component is seen as a white box when you are interested in its organization and operation: it is the point of view of the designer, the manufacturer, the repairer.
Similarly, a module will typically have:
- An interface that specifies the functions and procedures provided to the user
- A body performing them, using any desirable local function or procedure; this locality will be a guarantee against external corruption.
- If the module body has to exist, only knowledge of the interface is necessary for its use.
- Improving an application will remain simple if you improve the body of critical modules without changing their interfaces;
- Reusing a known module will be easy.