7/27/2019 Modular Programming Techniques

1/1

Modular Programming techniques:----------------------------------------------"Modular Programming" is the act of designing and writing programs as interactions among functions that each perform a single well-defined function, and which have minimal side-effect interaction between them. Put differently, the content of each function is cohesive, and there is low coupling between functions. Language support can be provided by a ModuleSystem.

"Modular Programming" discourages the use of control variables and flags in parameters; their presence tends to indicate that the caller needs to know too muchabout how the function is implemented. Like, having a "Customer I/O" function that takes an enumeration to (#1) Read a customer record, (#2) Insert a new record, (#3) Update an existing record, or (#4) check to see if this customer alreadyexists on disk -- would be bad. However, even good modular designs make some useof flags, for "end of file" indication, for example.

"Modular Programming" tends to encourage splitting of functionality into two types: "Manager" functions control program flow and primarily contain calls to "Worker" functions that handle low-level details, like moving data between structures.

ObjectOriented programs are usually modular. ModularProgramming does not have tobe ObjectOriented. The difference is that "merely" Modular code does not need to be associated with data (at least the way ObjectOriented code is structurally

associated with data.)

Modular Programming is heavily procedural: The focus is entirely on writing code(functions). Data is passive. Any code may access the contents of any data structure passed to it. (There is no concept of encapsulation.)

This is somewhat misleading. See DatabaseNotMoreGlobalThanClasses and GateKeeper.

To be reasonably cohesive, modular functions should not be excessively large; functions with over a page of code will be frowned upon. It's generally assumed that the code within each modular function will conform to the rules of StructuredProgramming. -- JeffGrigg

I do not agree that there is no concept of encapsulation in modular programming.The module or unit is where a lot of encapsulation occurs. For a real world example of modular programming, download Blackbox Oberon Component Pascal. For my thoughts on Modular Programming you can see my web page article about why it offers swapping benefits and debugging benefits for a real world project in use. http://z505.com/powtils/mop.shtml

Modular programming is just a concept. You can apply modular programming practice in any language, especially ones that are procedural in nature, which have separate compilation... and preferably units or modules (a.k.a modula, componentpascal, ruby, modern pascal, C (to an extent the C files can be modules) ).

I think a lot of the OOP hype exists because MOP (modular oriented programming)was never defined and marketed. In a lot of the software that I develop for thereal world, I use modular programming practices. Sure I sometimes use objects and classes, but they are not gospel or bible.