Directives

Create Modules That Have Strong Cohesion

The importance of procedures is usually better understood than that of modules a procedure is a section of code that performs a unified function. Unfortunately, for many developers the role of the module is a bit more confusing. A module is often wrongly thought of as a mere container used to store procedures. Some developers even take this idea to an extreme and put all their procedures into a single module ugh!

One reason that modules don't always get the consideration they require is that the implementation of modules really doesn't affect the execution of a program. When a project is compiled, it doesn't matter whether all the procedures are in a single module or in dozens of modules. But while the number of modules doesn't matter much to the actual execution of code, it matters a great deal when it comes to creating code that is easier both to debug and to maintain.

Modules should be used to organize sets of related procedures. In most applications, it's fairly easy to group procedures by some sort of commonality. For example, you might group all the routines in a contact management program that manipulate a contact record. You would put these related procedures in a single module with a name that describes the common purpose of the procedures, such as mdlContact. A procedure that opens a contact database, however, and that doesn't directly manipulate a contact record probably wouldn't belong in the contact module.

More Information

In many cases, a class is a better choice than a standard module. Refer to Chapter 11 for information on creating classes.

 

When a module contains a set of procedures that are tightly related, the module is said to have strong cohesion. When a module contains a number of more or less unrelated procedures, it's said to have weak cohesion. You should strive to create modules with strong cohesion.

Most projects contain a number of procedures that don't quite fit into a group with other procedures. In such cases, it's perfectly acceptable to create a catch-all module for these loners, perhaps named mdlGlobal, mdlUtilities, or mdlSupport. As the project grows, however, keep an eye on these modules and watch for situations where groupings appear then consider creating new modules or classes for the groupings. By creating specialized modules, you'll promote stronger cohesion. The quantity of modules in a project is not nearly as important as the quality of the organization. A very large Visual Basic project might contain only a dozen or so modules, but they should be very well constructed modules.

A set of organized modules might look something like Table 2-2.

 

Table 2-2. Example of Organized Modules

Module	Procedure
mdlContact	CreateContact
	DisplayContact
	DeleteContact
mdlDatabase	CloseDatabase
	CreateDatabase
	OpenDatabase
mdlUtilities	ShowOpenFileDialog
	ShowSaveFileDialog

 

When building modules, think of what the term modularization means. The principal idea with modules is to create fairly self-contained units. The ultimate module is one that can be added to another project and used immediately by calling its public procedures. Such a universal module doesn't rely on global data or on procedures within other modules. In reality, this second point is very hard to implement; it's difficult to create modules that don't contain at least a few calls to procedures in other modules, but it's a worthy goal.

If you're familiar with programming class modules to create reusable objects, the general principles of modules should sound familiar to you. Creating an entity that contains all of its code (local procedures) as well as its own data (module-level variables) is known as encapsulation, and this is the principal idea behind object-oriented programming. If you're able to create a perfectly encapsulated module, you should seriously consider creating it as class module and manipulating it as an object. (Refer to Chapter 11 for information on classes.)