[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]
