# \[AS2 OOP\] Addicted to globals! What are the alternatives?

**URL:** <https://forum.kirupa.com/t/as2-oop-addicted-to-globals-what-are-the-alternatives/182992>\
**Category:** flash\
**Created:** [March 23, 2006, 12:44am UTC](https://forum.kirupa.com/t/as2-oop-addicted-to-globals-what-are-the-alternatives/182992 "2006-03-23T00:44:23Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Matthew\_Ford](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matthew\_Ford](https://forum.kirupa.com/u/Matthew_Ford)\
**Post date:** [March 23, 2006, 12:44am UTC](https://forum.kirupa.com/t/as2-oop-addicted-to-globals-what-are-the-alternatives/182992/1 "2006-03-23T00:44:23Z")

</div>

[FONT=Arial]Hi everyone! My name is Matthew and I am a recovering globals addict.[/FONT]

[FONT=Arial]I would so much like to avoid the classic problems of using globals and anything like them. By globals I mean objects and other properties which any code anywhere can easily access reliably. I know that they can bloat and be hard to keep track of; they can get corrupted from anywhere in code; they reduce reusability; and so on.[/FONT]

[FONT=Arial]In my game app I have some “pseudoglobal” values and objects which are needed for read/write by many objects at many levels. For example:[/FONT]  
[FONT=Arial]–playfield width[/FONT]  
[FONT=Arial]–objects that hold data about “person” entities [/FONT]  
[FONT=Arial]–the interface mode[/FONT]  
[FONT=Arial]–system options[/FONT]  
[FONT=Arial]–common sound effects[/FONT]  
[FONT=Arial]–and so on[/FONT]

[FONT=Arial]I have some classes, the names of which hopefully make their basic function obvious:[/FONT]  
[FONT=Arial]–Room (of which there can be many instances)[/FONT]  
[FONT=Arial]–Person (ditto)[/FONT]  
[FONT=Arial]–Menu[/FONT]  
[FONT=Arial]–Tooltip[/FONT]  
[FONT=Arial]–VideoStream[/FONT]  
[FONT=Arial]–And so on[/FONT]

[FONT=Arial]Since the \_global keyword is being deprecated in AS3 I thought I was partially redeeming myself by storing the “pseudoglobals” described above as static properties of a class (such as playfield width), or as members of a static array (the people objects). But I’ve been told that it’s not really weaning me off of \_global. Kind of like getting off heroin but hooked on methadone. A few related questions I’d then have are the following and I’d really appreciate any thoughts:[/FONT]

[FONT=Arial]1) If I use getter/setter functions for these statics, thereby enforcing a bit more security and allowing easy tracing of writes to them, is that any better?[/FONT]

[FONT=Arial]2) If not, what are my alternatives to using the statics I describe above? They seem to be the following, all of which seem in my clouded mind to be equally hazardous or clumsy:[/FONT]

[FONT=Arial]–a) Code each one down as far into single classes as possible, so some of them can become accessible through this.\<property\> and \_parent.\<property\>. But it seems many of them just won’t push down; they are needed by at least two major classes.[/FONT]

[FONT=Arial]–b) Stamp onto all instances of everything a pointer to a “God” object to which these pseudoglobals are connected. So access is done through this.godObj.\<property\>. That seems like a lot of instance overhead and a lot of stamping, any one of which can be malformed.[/FONT]

[FONT=Arial]–c) On instance creation, pass along these pseudoglobals and have the constructor store them into local private vars, making each class access it through this.\<property\>. That seems like a lot of parameters to pass.[/FONT]

[FONT=Arial]–d) Have all instances use “\_parent”, “\_parent.\_parent”, and so on, to walk up the chain to the game instance that owns it, in which these pseudoglobals are properties. That seems like it will break a lot if I move instances deeper or shallower in my object chains.[/FONT]

[FONT=Arial]–e) Make all my classes sub- or sub-sub-classes of the Game class and let inheritance expose these pseudoglobals, which are properties of the Game class, to all subclasses. So access is done just through \<inherited property\> or super.\<inherited property\>. That seems like it may needlessly deepen the subclass chains and make it more puzzling to figure out where the value is coming from.[/FONT]

[FONT=Arial]3) I think I understand Singleton: I assure that there is only one instance of Game, and therefore I always can refer to its instance confident that it’s the only one. Using Flash’s F1 Singleton example, I could use gameObj = Game.getInstance() and then access gameObj.\<property or method\>. If I use Singleton, can I now use gameObj safely as the home of the pseudoglobals I describe above? Or is that just as bad as using statics?[/FONT]

[FONT=Arial]I appreciate the help I’ve gotten here so far. I feel like I am really getting somewhere![/FONT]
