4. Making the same data available to different modules


There are two methods of sharing the data held in variables between subroutines in a software project. 

  • Firstly, the variable can be made available for access by the subroutine or module. 
    • This involves altering the scope of the variable so it is shared directly by the subroutines. 
    • Global variables are an extreme example where the variable can be accessed directly by all parts of the program. 
  • Secondly, the data can be passed to the subroutine via parameters. 
    • In 8.2.1.2.5, we discussed the concept of parameters. 
      • Parameters are not variables, rather they are identifiers used to communicate data between subroutines within software. 
      • Wherever possible it is preferable to use parameters. 
      • Use of global variables makes it difficult to debug code and even more difficult to develop subroutines suitable for reuse.
Sharing variables by altering their scope 

The scope of an identifier is all the places within the program from which the identifier can be accessed. The idea of scope relates to all identifiers not just those associated with variables. For our current purposes let us restrict our discussion to
variables.

Local variables can only be accessed by the subroutines in which they are declared.
  • In this case other subroutines are unable to directly access these variables. To these other modules the variables simply do not exist. An instance of the local variable is created as the subroutine begins execution and is destroyed once the subroutine ends. 
  • If a subroutine is being called numerous times then its local variables will be created and destroyed numerous times.

Global variables, on the other hand, are available to other modules within the project.
  • They are created as the program starts and are only destroyed when the program finally ends. 
  • It is normally considered bad practice to use global variables, however there are some exceptional circumstances where the use of global variables is convenient. 
  • When global variables are used extensively in larger projects, it becomes difficult to track how and where they are altered. Also, the use of global variables within projects makes it difficult to reuse subroutines and modules in other projects.
  • They do however provide a simple mechanism for sharing variables between subroutines and modules.
Parameter Passing

The most common and best way to share data between different subroutines is through the use of parameters. 

  • The use of parameters, rather than global variables, greatly assists in the development of reusable self-contained modules. 
  • In fact, global variables should not be used in modules that will be included in libraries of code, particularly if these modules are to be distributed and used by others.
    • Consider the use of compiled modules of code. 
    • In these circumstances, there is no simple way of knowing the memory address of variables used by a particular subroutine. 
  • We have no alternative but to use parameters to communicate data to the subroutine. 
    • In fact, we do not even know or require the names of the identifiers used in the original source code, we just need to know their order and data type. 
    • For example, a square root function is available as a built-in function in most languages.There is no need for us to know the name of the identifier used as the parameter, rather we just need to know that it is a number and that the function will return a number.







Comments