[Tutor] Getting rid of global variables

[Sean 'Shaleh' Perry]

> 
> In C++ I've found that it often ends up that the most straightforward
> way to do things is to "cheat" with a global variable or two.  Otherwise
> I'd end up with a bunch of "manager" classes that make the program much
> harder to understand than it would have been had I just made everything
> global to begin with.
> 

Like all rules it is important to understand why the rule exists and decide if
that makes sense for the current application.

Globals are hated and feared because they create hidden and problematic
dependencies in your code.  You have this nice function you want to reuse and
discover "oh, I need THIS_VARIABLE" and things start to go bad.  Another reason
is globals are almost guaranteed to break threading code.

> To me the the situation you're describing sounds similar.  I hope my
> tiredness isn't causing me to misunderstand the problem, but the "who
> takes care of..." question suggests to me a "manager" class might be
> called for.  
> 

perhaps, or perhaps he needs a State class.  This would allow multiple
mailboxes, users, etc.

> 
> Part of this is because the manager class ends of duplicating the
> functionality of the class.  For example, a situation I've often faced
> in the past in working with C++ is how to handle a "master collection"
> of objects that I'd ideally like to make global.  The temptation was to
> make some sort of ListManager class that handled the list.  This class
> would have to provide methods for add, delete, find, etc.  But why
> bother when lists have this built in?  
> 
> So the next thought is to just put the list inside a class and make it a
> public variable.  This is simpler, but BZZZT - it's cheating!  Making
> variables public is a violation of good OO-style.  So at this point I
> had to choose which OO convention to violate.  I chose to make the lists
> global, my reasoning being that making it global left the cleanest code.
> 

another approach is to use singleton style classes with a static member that
returns the instance.

class Foo {
public:
  Foo* instance(void) { return singleton; }
};

Foo::instance()->method();

> The nice thing is that Python programmers tend to have a more liberal
> attitude towards globals, so using them is not really considered
> flagrant cheating like it would be in C++.  :-)
> 

part of the C++ (and software industry) hatred of globals is the threading
issues they create.  Globals guarantee problems when it comes time to refactor
or grow.

> 
> - DON'T read a book like Code Complete and feel you have to
> revolutionize your way of doing things overnight.  It would be foolish
> for a craftsperson to buy a tool kit and then try to learn to use them
> all on a current project, so why try to do that when coding?  Apply what
> you can understand now - this will still make your code that much
> better.  Later on you might find a better way to do things, and if the
> situation calls for it you can upgrade the program.  If not, at least
> you saved yourself a bunch of frustration.
> 

This is very important and several of the good programming books comment on
this.

It is good to reevaluate your approach to programming.  However when you start
using every nifty tool in the box other people look at your code and can see
it.  A consistent style is more important than crafty uses of the language.