Tip of the Iceberg

Category domino
Sorry, got a bit carried away there. It's just that I've become something of a refactoring addict lately. Maybe it's because I don't have the luxury of constantly refactoring my code at work, so stuff I play with at home (or, in this case, at a Ramada outside Memphis) gets refactored over and over again because I get a kind of buzz off of paring code down to its absolute essentials. I think maybe it's the programmatic equivalent of having a garage sale every few days... get rid of everything I don't need, find cool stuff in the attic that I forgot I even had, etc.

So I got an idea while driving today (15 hours of driving through the Great American Emptiness provides plenty of good musing time): judicious use of Static might trim this down even more. I don't really use Static... either I've never had a need for it, or just haven't discovered its true potential yet, but mulling over the nature of how the members of our little abstract singleton are initialized, it occurred to me that this might be a perfect place to use it.

Consider: a Boolean is automatically initialized to False. Static causes a variable's value to be saved between calls to the same procedure. So... instead of using Private Boolean class members to keep track of whether other members have already been initialized, how's about moving them inside the various Subs that initialize those members, but making them Static? That way, the first time each initialization sub is called, the corresponding Boolean is False, so initialization will take place, but the next time it will have become True, so initialization will be skipped. In other words, the same thing it's doing now... except that even the Booleans are not stored in memory until each is needed. I know, Booleans only take up 2 bytes, but if this class is expanded (or extended) to keep track of a large number of objects - which it could be, since it only grows as large in memory as the code calling it requires it to - this approach might help it to scale even better.

I'll discuss this with Chad and see what he thinks. Actually, Chad, if you're reading this, let me know what you think. Maybe I'm dwelling on this one topic too long, but it's already saved me a bunch of time, so I can't help wanting to refine it even more.