Modular programming

The principle of modularity is a means of simplifying the task of designing software and distributing the development process of software among development teams. When dividing the PS into modules for each module, the functionality it implements is indicated, as well as communications with other modules. ^[2] Ease of use of modular architecture is the ability to update (replace) the module, without the need to change the rest of the system.

The role of modules can be played by data structures , libraries of functions , classes , services, and other program units that implement some functionality and provide an interface to it.

Program code is often split into several files, each of which is compiled separately from the rest. Such modularity of the program code can significantly reduce the recompilation time for changes made only to a small number of source files, and simplifies team development . It is also the ability to replace individual components (such as jar files , so or dll libraries) of the final software product, without the need to rebuild the entire project (for example, developing plugins for an already finished program).

One of the methods for writing modular programs is object-oriented programming . OOP provides a high degree of modularity due to properties such as encapsulation , polymorphism and late binding .

Despite the fact that modular programming is in no way connected with the details of a particular language (and even if there is no explicit support from the language, it can be applied with sufficient discipline from the programmers), most languages ​​push their own nature of the module system to the upper level, like transferring a system modules from one language to another would be impossible ^[3] .

In 2000, Xavier Leroy proposed making module systems modular, that is, parameterized by describing a specific core of the language with its own type system ^[3] . As an example, he demonstrated a generalized implementation of the ML module language (as the most developed system of modules currently known) and examples of its instantiation into the ML language traditional for it and the C language.

Leroy’s implementation itself is built using the ML module language , namely, in the form of a functor parameterized with data on the language core and a description of its type checking mechanism. This means that when writing a compiler of a certain language, it is enough to describe the core of the language and pass it to this functor (as a library function) - as a result, you will get a compiler for extending the known language with the ML module system .

The history of the concept of modules as compilation units goes back to the languages ​​of Fortran II and Kobol , that is, by the end of the 1950s ^{[4] [5]} . In 1976, a publication appeared in which the concept of modularity was developed - about the Mesa language , which was developed at Xerox PARC . In 1977, the scientist Nicklaus Wirth got acquainted with this concept in detail, talking with developers at Xerox PARC. ^[6] These ideas were used by Wirth to create the language of Modula-2 , the publication of which was published in 1977 ^[7] .

The term "module" in programming began to be used in connection with the introduction of modular principles in creating programs. In the 1970s, a module was understood to mean a procedure or function written in accordance with certain rules. For example: “the module should be simple, closed (independent), visible (from 50 to 100 lines), realizing only one function of the task, having one input and one output point”.

First, the main properties of a software module were more or less clearly formulated by David Parnas in 1972 : "To write one module, minimal knowledge about the text of another should be enough." Thus, in accordance with the definition, a module could be any separate procedure (function) of both the lowest hierarchy level (implementation level) and the highest level, at which only calls to other module procedures occur. ^[eight]

Thus, Parnassus was the first to put forward the concept of information hiding in programming. However, only syntactic constructions that existed in the languages ​​of the 70s, such as a procedure and a function, could not provide reliable information hiding due to the widespread use of global variables.

It was possible to solve this problem only by developing a new syntax construct that is not affected by global variables. This design was created and called the module. Initially, it was assumed that in the implementation of complex software systems, the module should be used along with procedures and functions as a design that combines and reliably hides the implementation details of a specific subtask.

Thus, the number of modules in the complex should be determined by the decomposition of the task into independent subtasks. In the extreme case, the module can even be used to conclude in it just one procedure, if it is necessary that the local action it performs is guaranteed to be independent of the influence of other parts of the program with any changes.

The specialized syntactic construction of a module was first proposed by N. Wirth in 1975 and included in his new language, Modula. How strongly the properties of the language change with the introduction of the mechanism of modules is evidenced by the following remark by N. Wirth regarding his later language of Modula-2: “Modules are the most important feature that distinguishes the language of Modula-2 from its predecessor Pascal.”

Languages ​​formally supporting the concept of modules: IBM S / 360 Assembler , Kobol , RPG , PL / 1 , Ada , D , F (English) , Fortran , Haskell , Blitz BASIC , OCaml , Pascal , ML , Modula-2 , Oberon , Component Pascal , Zonnon , Erlang , Perl , Python, and Ruby . The IBM System used “modules” from the RPG , Cobol, and CL languages ​​when it was programmed in the ILE environment.

Modular programming can be done even when the syntax of the programming language does not support explicit naming of modules.

Software tools can create modules of source code, presented as part of groups - components of libraries that are compiled with the program by the linker .

Standard Pascal does not provide mechanisms for separate compilation of parts of a program with their subsequent assembly before execution. The desire of developers of commercial Pascal compilers to include in the language tools that increase its modularity is quite understandable. ^[9]

A module in Pascal is an autonomously compiled program unit that includes various components of the description section (types, constants, variables, procedures, and functions) and, possibly, some executable operators of the initiating part. ^[ten]

By their organization and the nature of their use in the program, Pascal modules are close to the PACKAGE modules of the Ada programming language. They, just as in Ada’s packages, explicitly highlight some “visible” interface part, in which descriptions of global types, constants, variables are concentrated, as well as the headers of procedures and functions. The appearance of objects in the interface makes them available for other modules and the main program. The bodies of procedures and functions are located in the executable part of the module, which can be hidden from the user.

Modules are a great tool for developing application libraries and a powerful modular programming tool. An important feature of modules is that the compiler places their program code in a separate memory segment. The segment length cannot exceed 64 Kbytes, however, the number of simultaneously used modules is limited only by available memory, which allows you to create large programs.

• Application Programming Interface
• Abstract data type
• ML Module Language
• Microservices

• Xavier Leroy. A Modular Module System // vol. 10, issue 3. - Journal of Functional Programming, 2000 .-- pp . 269-303 .