Create Modules That Have Strong Cohesion

[Previous] [Next]

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 if 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.

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 catchall 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 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 this:

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 Visual Basic's 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 perfectly encapsulated modules, you should seriously consider creating them as class modules (rather than standard modules) and manipulating them as objects.



Practical Standards for Microsoft Visual Basic
Practical Standards for Microsoft Visual Basic .NET (Pro-Developer)
ISBN: 0735613567
EAN: 2147483647
Year: 2000
Pages: 57

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net