Nine people.  An optical illusion that demonstrates how something we should be able to recognize easily may be obscured.Modular Hierarchy

By J. W. Rider

J. W. Rider Consulting

http://www.jwrider.com

October 2004

 

What constitutes a “module” often depends upon our backgrounds.  For programmers, a module is equivalent to a function or subroutine.  However, the notion of modularity goes far beyond simply being able to group statements together and give the group a common name. Modularity is infused throughout modern programming languages. If you don't look closely, you might not be able to see the forest because of all the trees that have gotten in the way.

Modularity is used for a broad spectrum of organizational activities inside of programs.  At the very bottom is the most elementary of program design concepts: the statement.  It might not be obvious that a statement is a kind of module, but each and every single statement is an abstraction of multiple machine instructions.  Sequences of statements may be grouped into blocks.  Blocks and conditions may be organized recursively into selective or iterative constructs.  Constructs are organized into functions or subroutines.  (This last form of organization is the only one that many textbooks discuss as being a module.) Functions and variables are organized into libraries or object-oriented classes.  Classes are organized into units or packages. Packages are used to create programs.

We don’t have to stop there. We could go on to organize programs into applications or distributions.  However, this hierarchy should be sufficient to give you an idea of the richness of the modularity concept in programming design.

In some ways, the notion of modularity has always driven how programmers view a program.  In the early days, programs were seen primarily as a collection of machine instructions.  While the machine instructions didn’t go away, the advent of high-level programming languages encouraged programmers to think of programs as a collection of statements.  Modular programming told programmers to consider programs as a collection of more complex functions.  The object-oriented programming paradigm has shown programmers the benefits of visualizing programs as collections of interrelated objects, all working together to solve a single problem. 

It would be way too arrogant of us to think that we now know all modularities that might occur within program design.  At this very moment, there could be someone, someplace, who’s just on the verge of recognizing a new and useful way to combine together the machine instructions and information within software.  New concepts of modules are just around the corner.  However, these are just new ways of looking at software.  The old ways will still have their utility.