Page 203 - DCAP408_WEB_PROGRAMMING

Unit 12: Dialog Boxes (II)

 Implicit coupling: A program with many global variables often has tight couplings between Notes
some of those variables, and couplings between variables and functions.

Did u know? Grouping coupled items into cohesive units usually leads to better programs.
 Concurrency issues: If globals can be accessed by multiple threads of execution,
synchronization is necessary (and too-often neglected). When dynamically linking modules
with globals, the composed system might not be thread-safe even if the two independent
modules tested in dozens of different contexts were safe.
 Namespace pollution: Global names are available everywhere. You may unknowingly
end up using a global when you think you are using a local (by misspelling or forgetting
to declare the local) or vice versa. Also, if you ever have to link together modules that
have the same global variable names, if you are lucky, you will get linking errors. If you
are unlucky, the linker will simply treat all uses of the same name as the same object.

 Memory allocation issues: Some environments have memory allocation schemes that
make allocation of globals tricky. This is especially true in languages where “constructors”
have side-effects other than allocation (because, in that case, you can express unsafe
situations where two globals mutually depend on one another). Also, when dynamically
linking modules, it can be unclear whether different libraries have their own instances of
globals or whether the globals are shared.
 Testing and Confinement: Source that utilizes globals is somewhat more difficult to test
because one cannot readily set up a ‘clean’ environment between runs. More generally,
source that utilizes global services of any sort (e.g. reading and writing files or databases)
that aren’t explicitly provided to that source is difficult to test for the same reason. For
communicating systems, the ability to test system invariants may require running more
than one ‘copy’ of a system simultaneously, which is greatly hindered by any use of
shared services – including global memory – that are not provided for sharing as part of
the test.
12.2.2 Why the Convenience of Global Variables sometimes Outweighs
the Potential Problems?

 In a very small or one-off programs, especially of the ‘plugin’ sort where you’re essentially
writing a single object or short script for a larger system, using globals can be the simplest
thing that works.

 When global variables represent facilities that truly are available throughout the program,
their use simplifies the code.
 Some programming languages provide no support or minimal support for non-global
variables.
 Some people jump through very complicated hoops to avoid using globals. Many uses of
the Singleton Pattern are just thinly veiled globals. If something really should be a global,
make it a global. Don’t do something complicated because you might need it someday. If
a global variable exists, I would assume that it is used. If it is used, there are methods
associated with it. Even in the above cases, it’s wise to consider using one of the Alternatives
to Global Variables to control access to this facility. While this does help future-proof the
code.

LOVELY PROFESSIONAL UNIVERSITY 197