Modular programming: Difference between revisions

Revision as of 13:38, 28 September 2021

Revision as of 13:47, 28 September 2021

Line 20:

Modular programming can be performed even where the programming language lacks explicit syntactic features to support named modules, like, for example, in C. This is done by using existing language features, together with, for example, [[coding conventions]], [[programming idioms]] and the physical code structure. [[IBM i]] also uses modules when programming in the [[Integrated Language Environment]] (ILE).

==Key aspects==

With modular programming, [[separation of concerns|concerns are separated]] such that modules perform logically discrete functions, interacting through well-defined interfaces. Often modules form a [[directed acyclic graph]] (DAG); in this case a cyclic dependency between modules is seen as indicating that these should be a single module. In the case where modules do form a DAG they can be arranged as a hierarchy, where the lowest-level modules are independent, depending on no other modules, and higher-level modules depend on lower-level ones. A particular program or library is a top-level module of its own hierarchy, but can in turn be seen as a lower-level module of a higher-level program, library, or system.

When creating a modular system, instead of creating a monolithic application (where the smallest component is the whole), several smaller modules are written separately so when they are composed together, they construct the executable application program. Typically these are also [[Compiler|compiled]] separately, via [[separate compilation]], and then linked by a [[Linker (computing)|linker]]. A [[Just-in-time compilation|just-in-time compiler]] may perform some of this construction "on-the-fly" at [[Run time (program lifecycle phase)|run time]].

These independent functions are commonly classified as either program control functions or specific task functions. Program control functions are designed to work for one program. Specific task functions are closely prepared to be applicable for various programs.

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 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{{By whom|date=July 2021}}, 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).

==History==