Global Variables vs Data Duplicates

[scc]

This is actually for a Flash website project (so is written in ActionScript), but is relevant to all OO languages.


I haven't done a massive amount of OO programming, but I know the basics. Where I fall short is a lot of the best practices... I know that global variables are to be avoided wherever possible and that passing variables to classes and functions is the way to go instead, but I've also read many times that having multiple copies of data in different places is a bad idea, which also makes perfect sense to me but these seem to conflict in certain situations.


The problem I have with this is best illustrated with a current design issue I'm scratching my head over:


I've got a flexible UI design which resizes to the window size, but I've set a maximum size (800 x 600), so there's essentially a frame within the flash design which everything is contained within - this will resize to fit the window if it's less than 800 x 600 or stay at 800 x 600 if the window's bigger than that.

A lot of the components in my design rely on knowing the current frame size (for positioning etc), which is calculated from the window size obtained from the standard Stage object in Flash. The 4 options I can think of for handling this frame size variable are:

1. Have a _global variable: bad practice, particularly if this movie is at some point embedded into another movie as it may conflict.

2. Have a variable in a separate or top-level class: a bit of a referencing nightmare, every component has to be passed either a reference to this class or the variable itself (which goes against my interpretation of encapsulation) - if the latter, then problems occur as the components don't just need the variable at the moment when the window is resized (as certain animations rely on the mouse position relative to this frame) so the variable would have to be stored locally in each component = data duplication = bad practice.

3. Calcuate the variable locally: would have to be performed every time the window is resized or whenever it's needed, not very efficient and also means data duplication = bad practice again.

4. Using static variables: all of the components are defined as extending from the same class, so I could give this class a static variable, either of the frame size variable itself or a reference to a class which contains the variable. Then I wouldn't need to pass a reference to an the object with the variable (or the variable itself) to every component, I just have to set it once for the class. The only issue with this is it relies on all components extending the same class, which may not always be the case (even if it is in the app's current state).

Or I could store the frame size as a static variable within a separate class, which could then just be obtained by Class.variable without needing to know an instance name... although if I wanted to drop a component using this system into another app, the class storing the variable would have to have the same name, or I'd have to edit the code of the component.



What would you do here? Is there another technique I haven't spotted? What would be considered the best programming practice?

Thanks

[WingedPanther]

Perhaps a better tactic would be to think about WHY the various solutions are issues.

Global variables: bad because a sub-process can change it in the middle of a parent process's work. If the parent isn't aware of the change, you can get invalid results and have a bug that is hard to track down because the change was made in a completely different section of code.

Local variables: especially in recursion, this can create thousands of instances of variables, which is a massive resource hog. In most situations these are not a major concern.

References to variables: This is often a compromise between the above two: you give a function access to an outside variable (via pointer, reference etc) in a controlled way while not creating duplicate instances of it. Most languages will provide a way for it to be obvious this is potentially changing a variable's value.

The best practice depends on the circumstances.

[scc]

Thanks, yeah I think you're right - I do tend to have it in my head that if I can find a design pattern that ticks all the boxes, I'll be able to approach most things like that but as you say the ideal way to do something can vary hugely depending on what you're doing.

I think steering clear of local variables for a comparatively global property makes sense as from a scalability point of view what you say very much applies - I'm hoping I'll be able to reuse a lot of this code and if it gets reused in a bigger system, I don't want to have to worry about clogging up resources.

One suggestion a few people have made which I like the sound of is using a singleton approach - i.e. create a class with only one instance which returns a reference to that instance if you try to instance it again. This way I won't have to pass references around, so I think that's the route to go down in this case.

Thanks for your help.

[WingedPanther]

As your project gets larger, try to be aware that global variables can cause issues if multiple programmers are accessing it. Just another point against globals.

[keller]

I think steering clear of local variables for a comparatively global property makes sense as from a scalability point of view what you say very much applies - I'm hoping I'll be able to reuse a lot of this code and if it gets reused in a bigger system, I don't want to have to worry about clogging up resources.

In OO languages as long as garbage is being collected (automatically or manually) then you aren't hogging resources if you are using good algorithms. Remember that local variables are only in use as long as you are still in their scope, and once you leave their scope then that memory is freed by you or the garbage collection system. If you have a great deal of persistent data in your program then you might consider linking a database or using a file for data storage instead of using ram. Using global variables can lead to major issues later on down the road especially if the project is large. I have seen a number of program that had nearly untrackable errors that turned out to be global variables being overwritten by functions and methods. Just save yourself the hassle down the road and invest a little extra time and do it right the first time.