oopOnly lazy people haven’t written already about how global variables are evil. It started in 1973 when W. Wulf et al. claimed that “the non-local variable is a major contributing factor in programs which are difficult to understand.” Since then, many other reasons where suggested to convince programmers to stop using global variables. I think I read them all, but didn’t find the one that bothers me most of all: composability. In a nutshell, global variables make code difficult or impossible to compose in ways which are different from what its original author expected.
I was recently writing a web front for Zold in Ruby, on top of Sinatra. This is how a web server starts according to their documentation:
App.start!
Here start! is a static method of the App class, which you have to declare as a child of their default parent Sinatra::Base. To tell the app which TCP port to listen to you have to preconfigure it:
require 'sinatra/base'
class App < Sinatra::Base
get '/' do
'Hello, world!'
end
end
App.set(:port, 8080)
App.start!
What do you do if you want to start two web servers? For the purpose of testing this may be a pretty logical requirement. For example, since Zold is a distributed network, it is necessary to test how a number of servers communicate to each other. I can’t do that! There is absolutely no way. Because Sinatra is designed with the assumption that only one server may exist in the entire application scope.
Can this really be fixed? Let’s take a look at their code. Class Sinatra::Base is essentially a Singleton, which is not supposed to have more than one instance. When we call App.set(:port, 8080), the value 8080 is saved into an attribute of a single instance. The number 8080 becomes available for all methods of Sinatra::Base, no matter what instance they are called from.
They are not using true Ruby global variables, I believe, because they know that they are bad. Why exactly they are bad and what the alternatives are—slipped through their fingers.
Technically speaking, their design is “globally scoped.” Sinatra::Base treats the entire application as its scope of visibility. No matter who calls it, everything is visible, including what was created in previous calls and in previously instantiated objects. This “class” is a giant bag of global variables.
Every global variable is a troublemaker of that kind. While the application is small and its test coverage is low, global variables may not hurt. But the bigger the app and the more sophisticated its automated testing scenarios, the more difficult it will be to compose objects which depend on global variables, singletons, or class variables.
My recommendation? Under no circumstances even think about any global variables.
What do you think about global variables? #elegantobjects #oop
--- Yegor Bugayenko (@yegor256) July 15, 2018
