Coupling and Cohesion

Here's a topic that isn't specific to VBA, but bears mentioning while we are working with procedures. The design of your procedures is very important to delivering understandable, readable code. Two principles that guide the logical design of procedures (functions or subs) are coupling (bad) and cohesion (good).

Coupling is the tempting tendency to write long, complex procedures that do lots of things; in other words, coupling together multiple tasks into one procedure. It should be avoided. As a guideline, try to write procedures that compute one value or perform just one task. Some signs that you might have coupling tendencies in your procedures include:

□ Procedure names that include multiple ideas, like ComputeValuesAndReloadWorkTables

□ Procedure with large blocks of code that have section header comments that explain what this next section does

□ Procedures that include "modes," with parameters that tell the procedure what to do

If your procedure couples multiple tasks together, you can run into problems like these:

□ Your procedure is too complicated, making it harder to write and debug.

□ The different tasks in your procedure can't be used separately; it's an all or nothing deal.

□ If you make a change to your procedure, the whole thing needs to be retested. You can't trust that your little change didn't mess up other parts of the procedure. Remember the programmer's lament: "But all I changed was . . . "

If you find yourself writing long procedures with these coupling problems, take a deep breath and step back from it for a minute. Try to identify chunks of code that do something simple and cohesive. As a rule, procedures should do or calculate one thing, and should do so independently using parameters that are passed to them. They can also retrieve information from tables or queries to get the information they need.

You may wonder how to build procedures that really need to be complex. Sometimes there is no way to avoid complexity. However, you can hide a lot of complexity by breaking up your logic into smaller functions and subs, then calling them where appropriate. That way, each one of your procedures can be written and debugged separately. If you are working in a team environment, these can even be written by different developers.

Cohesion is related to coupling, but it's a good thing. It just means that each procedure should perform one function, and should be able to do its thing without a lot of help or knowledge from outside the procedure. It shouldn't rely on global variables or other objects to exist. Some signs of a poor cohesion are:

□ Procedures that include duplicate blocks of code

□ Procedures that expect forms or reports with specific names

□ Use of global variables, especially when they are expected to retain their value for a long time

□ Hard coding of system environment information like file paths

□ Hard coding or special handling of certain records or values in tables

Hard coding is the practice of using values in code that would be more appropriate in a configurable lookup table or some other easy-to-change place, for example, many poorly written applications hard code paths to files. The moment these applications are moved to another computer, they break. Another more insidious example is the use of values lists for combo boxes in forms. These seem so easy to set up, but they are just another form of hard coding that will make your application less robust and harder to change over time. A better approach for a list of values that you don't think will change (or that you need to code against) is to put them in a table that doesn't have a maintenance form. This prevents your user from adding or removing these critical values your code depends on, but allows you flexibility over time. You can use a specific naming convention for these "values list" tables, like tval instead of tlkp.

To improve cohesion, think of the old black box principle of programming, which specified that you should need no knowledge of how a procedure produces its result, only that given valid input, it would produce the correct output. Along the same lines, the procedure should have little knowledge of the world outside in order to do its job. Each procedure you write should perform one task or calculation. It should have a minimum of special knowledge from outside its own boundaries. The best way to send information into a procedure is through parameters, not by using global variables or by referring to specific forms or reports.

All this being said, cohesion is a spectrum, not a final black-or-white goal. Using VBA in Access sometimes calls for the use of global variables in controlled scenarios, or referring to an open form, or duplicating some code. It's best to be aware of coupling and cohesion principles so that you can make good coding decisions.

0 0

Post a comment