A Balance of Power
As a Flatiron bootcamp enrollee new to the world of software engineering and programming languages (Ruby to be specific), I have found myself drowning at many moments trying to wrap my head around the constant barrage of new subjects being thrown at me. In these moments of drowning I try to zoom out and gain perspective on any given subject as a whole in an effort to better understand how the subject works in its nitty gritty details. One specific subject that caused this zoom out moment was SCOPE. SCOPE as a concept manifests itself in Ruby when looking at the different variable types of the language. Ruby has a total of four variable types each ranging in SCOPE of influence. The four variable types are $global, @@class, @instance, and _local. They each have their own set of limitations defined by their SCOPE of influence. This diagram was a helpful visualizer for me to see who of the four can do what.
Ruby as a programming language was invented by Yukihiro “Matz” Matsumoto in the mid 1990’s. The language is referred to as an object oriented programming language or OOP for short. Ruby as a language is known for being easy to read and by design reflective of everyday life. As a new bootcamp student gasping for air I was struggling to wrap my head around this new language and how it could mirror the world I currently live in. SCOPE was the first subject where I had my a-ha moment.
Looking at the 4 variable types in ruby a little closer we have:
$Global: having the broadest SCOPE of the bunch and capable of being used and written to from ANYWHERE in the program.
@@Class: having the SCOPE relative to the entire class
@instance: having SCOPE relative to a single instance of a class
_local: having SCOPE limited to the moment when Ruby Interpreter sees it being assigned to something
Growing as a new Ruby programmer I have started to recognize a trend in how these variables are used throughout a programs implementation. You see far fewer $global variables in comparison to the other three and that is by design. While $global variables have the largest SCOPE and can be written to from anywhere in the program making them the most power of the 4 variable types we use them so infrequently to check or balance their power. While it might seem like a good idea to incorporate many $global variables in a given program it is quite the contrary.
Think of the US Government as an example here. The President of the United States could be seen as a metaphor for a $global variable. A sitting president has the many powerful tools in their belt. One of these is the power to send the United States to war when the country is under attack and in a state of national emergency. We limit that power to the president alone. On the other hand the president’s powers are checked by the legislative (Senate and Congress) and judicial (Supreme Court) branches of government . When not under direct attack the legislative branch must collectively vote in order to pass a declaration of war that the president would then have to approve.
While @@class and @instance variables do not keep $global variables in check they do a much larger majority of the work in a given program. Often programming in Ruby, reflecting real life, moves the majority of that work to @@class variables (Senators / Congress People / Supreme Court Justices), @instance variables (Mayor / Governor) or _local variables (Union Representative / PTA President). Looking back at our government metaphor we see that the president does not write legislation. The legislative branch does. Very similar to how @@class and @instance variables are used to update databases and frame methods that make a given program run!
Another very common real life application of this concept is called the Principle of Least Access(POLA). In this example we look at a bank and its employees. While the teller at a bank handles many of the day to day interactions with customers they are not given full access to edit a customers data or keys to the bank vault. The access is limited to managers who have that editing power and key access to prevent errors from occurring.
As a program developer you start to see how a given class and its @@class and @instance variables hold responsibilities for updating and editing our databases while a lonely _local variable or the all powerful $global variable do not. The scaling of SCOPE for the 4 classes of variables is a wise design to delegate responsibility and balance power across a given program.
The general consensus among Rubyists is that $global variables should be used sparingly if at all as they can be written and redefined anywhere inside the program. Having many $global variables in a given program usually will make isolating bugs difficult. What class or method modified the $global variable, when did they do that, because it is causing problems now? This phenomena is also referred to as breaking encapsulation. Debugging in larger programs would require lots of sifting through code and every instance of a $global which is why $global variables if ever used are usually in smaller programs.
While the comparison of Ruby SCOPE design to the US Government falls short in many ways the all powerful $global variable mirroring a US President is quite accurate. A sitting president is very powerful but is many ways serves as a figure head and in our current climate does very little work :). I am thankful that a president is limited in what they are capable of doing and as budding Rubyists we should also limit the use of $global variables.
References:
