TITLE: Are global variables evil?

AUTHOR: rmartin@rcmcon.com (Robert Martin), 25 Sept 95

This must be global month.  There are several different threads this
month that concern global variables.    Interesting.

Are global variables evil?  It would be wise if we would all realize
that "evil" is a poor term for the description of a tool.  It carries
an emotional weight that is inappropriate in this context.

There is a commonly held view that the use of global variables is
inappropriate and even dangerous.  Why should this be?   What
principles underlie this view?

One of the most important principles of OOD is the "open closed
principle" described by Bertrand Meyer in his book "Object Oriented
Software Construction", Prentice Hall, 1988.  This principle states
that a module should be open for extension but closed for
modification.  In other words, you should be able to change the
behavior of a module without changing the source code of that module.

Generally, this is accomplished by employing abstract base classes
with pure interfaces (pure virtual functions).  The pure interfaces
can be overridden in different modules so that the behavior of the
module containing the abstract class can be changed, without changing
the source code of the module.

Global variables present a particular problem for attaining closure.
Any module that depends upon a global variable cannot be closed
against changes to that variable.  Moreover, such modules cannot be
closed against changes in the way that other modules *use* that
variable.  Thus, a global variable represents a dependency which ties
all the modules which use it together, and prevents them from being
closed to changes in each other.

This means that, whenever any module changes the policy it uses to
manage a global variable, all other users of that variable are
potentially affected.  They must all be found and inspected to see if
the change in policy requires modification.

In a large application, the task of finding all these globals is
non-trivial. Once found, the task of determining whether the change in
policy requires modification is even harder.  And even the detection
that there has been a change in policy is not always clear cut.
Thus, global variables do represent a significant problem.   It is
these problems which foster the common view that globals are generally
dangerous.  

But adhering to a common view without understanding the reasoning
behind it is less than optimal behavior for a software engineer.
Slavish rejection of all global variables on the basis that they are
all intrinsically evil is shortsighted and immature.

There are uses of global variables which do not violate the open
closed principle; and are therefore quite benign.  Consider the
"Abstract Factory" pattern from the GOF book (Design Patterns, Gamma,
et. al., Addison Wesley, 1995).  This pattern, which enables the open
closed principle in a very sticky scenario, virtually requires the use
of a single global variable to hold the factory.  In this case, only
one module in the program makes changes to the global.  All others use
the value in the global but do not modify it.  Moreover, the concept
of the "Factory" is a global concept.  It applies to many modules
simultaneously.  

The moral here is that we should never proscribe a practice without
fully understanding the reasons behind that proscription.  Global
variables carry a high potential for violation of the OCP, yet there
are valid, even necessary, uses for them.  Software engineers should
not simply rely upon common conventions and religious proscriptions.
Rather they should learn the principles of software design so that
they can determine for themselves the cost/benefit of a given practice
in a given context.