Skip to main content
C
codeBeastAdobe
Inspiring
June 11, 2011
Answered

singleton vs normal/global variable

  • June 11, 2011
  • 2 replies
  • 3657 views

Hi just been looking intot he singleton pattern. WHY would I use this pattern to hold variables accessible to other swfs throughout the project when I can just keep them in the container movie and access them as desired.

Is there any advantage like optimization, security, ease of use  etc...

I'll post a second question re: how I access a varibale in a parent mc unless answered here too as it is in the same category.

Is it best to access a varibale in the parent using

1. MovieClip(parent.parent).variableTargeted

OR

import com.parentAsDocument;

And then access the variable

Thank you in advance

(btw . I have never seen this in any tutorials anywhere - and I have been reading for years - Am I missing something here or is this something advanced programmers only know because they read advanced books?)

This topic has been closed for replies.
Correct answer Andrei1-bKoviI

If I need to use global variables - I will most probably use public static properties (variables) and methods in a special class that is designed to provide the values of these variables (or functionality of static methods) to the entire application. Any object that gains reference to this class will be able to read/write these values.

You are already familiar with static properties. For instance when you add event listeners you write:

mc.addEventListener(Event.ENTER_FRAME, handler);

ENTER_FRAME is a static variable (and also a constant) that is accessible TO ANY other object in the application GLOBALLY.

As for the container question, I feel you are talking about top level code (timeline or document class). If my impressions is correct - no, I would never declare any static properties or methods for application-wide usage. As I said, I would create a special class and delegated this functionality to and then point other classes to it if needed.

Frankly, I would never use timeline for anything unless someone puts a gun against my head (or hands a lot of cash). As a matter of fact I avoid using Flash IDE altogether as a plague. I am saying that for a single purpose - timeline coding is treacherous (and, oddly, more complicated than class usage) and entice people not to think in OOP manner. The biggest drawback is that developers often assume that timeline provides some sort of assurances and conveniences and thus developers spent inappropriately little time thinking about application architecture in a more abstract manner.

I strongly suggest if you plan to excel programming skills to give up timeline coding as soon as possible (including using Flash altogether) and move toward Flash Builder or other environment. Benefits are awsome and you will never want to come back to timeline.

If you want me to - I will give you a more concrete example of how I would approach implementation of static aspects of classes.

2 replies

A
Andrei1-bKoviI
Inspiring
June 11, 2011

Oh, I forgot to mention that there are no global variables in AS3 in a sense they were in AS2. Variables on timeline are not global to application - they belong to local scope.

C
codeBeastAdobeAuthor
Inspiring
June 11, 2011

Hi Andrei - that was a big post BUT I failed to get a clear answer. It looks like the singleton pattern is not yoiur biggest friend. So you would go with just declaring the variables in the container swf and access them. And if so how exactly would you go about that?

I am NOT a professional programmer - just an amateur but I have got professional goals in mind.

Cheers

A
Andrei1-bKoviICorrect answer
Inspiring
June 11, 2011

If I need to use global variables - I will most probably use public static properties (variables) and methods in a special class that is designed to provide the values of these variables (or functionality of static methods) to the entire application. Any object that gains reference to this class will be able to read/write these values.

You are already familiar with static properties. For instance when you add event listeners you write:

mc.addEventListener(Event.ENTER_FRAME, handler);

ENTER_FRAME is a static variable (and also a constant) that is accessible TO ANY other object in the application GLOBALLY.

As for the container question, I feel you are talking about top level code (timeline or document class). If my impressions is correct - no, I would never declare any static properties or methods for application-wide usage. As I said, I would create a special class and delegated this functionality to and then point other classes to it if needed.

Frankly, I would never use timeline for anything unless someone puts a gun against my head (or hands a lot of cash). As a matter of fact I avoid using Flash IDE altogether as a plague. I am saying that for a single purpose - timeline coding is treacherous (and, oddly, more complicated than class usage) and entice people not to think in OOP manner. The biggest drawback is that developers often assume that timeline provides some sort of assurances and conveniences and thus developers spent inappropriately little time thinking about application architecture in a more abstract manner.

I strongly suggest if you plan to excel programming skills to give up timeline coding as soon as possible (including using Flash altogether) and move toward Flash Builder or other environment. Benefits are awsome and you will never want to come back to timeline.

If you want me to - I will give you a more concrete example of how I would approach implementation of static aspects of classes.

A
Andrei1-bKoviI
Inspiring
June 11, 2011

In my opinion these two statements:

"WHY would I use this pattern to hold variables accessible to other swfs throughout the project when I can just keep them in the container movie and access them as desired."

and

" I have never seen this in any tutorials anywhere - and I have been  reading for years - Am I missing something here or is this something  advanced programmers only know because they read advanced books?"

are related because, as I understand, you describe situation when application uses both timeline and class-based codes. The very concept of mixing them up is against best OOP practices.

Also it feels like you describe an unfortunately common approach when presentation layer (movie clip container) functions as an information layer which is no-no in the majoruty of cases. Objects should be as specialized as possible.

In addition, the approach:

MovieClip(parent.parent).variableTargeted

is not good as well. To begin with, it tightly couples data to object's position on display list (re: separation of presentation and information layers). The best written objects should exist/function independently for scalability reasons.

With that said, solid tutorials will never cover these kind of cases because, again, they are considered bad practices.

As for the singleton, there are two schools of thought. One is a very militant and rigid that states that singleton is the only way to go when there is a need for globally accessible properties and methods. Another said - it depends.


AS3, unlike other languages like Java, doesn't allow for true singleton pattern anyway. So, in the vast majority of cases it is an overkill and static methods and properties can be used instead.

So far the only case when so called "singleton" in AS3 is useful is when functionality cannot be used as static due to datatype specifics. For instance, there is no native way to dispatch static events - so using singleton allows for utilizing EventDispatcher functionality (of course static event dispatching can be written as well).

Design patterns in general often become a goal - not a tool. This is in addition to the fact that they are not so widely accepted as some want us to think. Very smart people have valid arguments against using existing design patterns.

We, Flash developers, have to be very mindful of our applications sizes and performance. Design patterns almost always introduce unnecessary overhead. In some case it doesn't really matter but in the majority of Flash applications it may be a deal breaker.

At the end of the day any of our applications end up with some sort of pattern. This is not to say that the idea of patterns is useless. It definitely has a value as reference point and, in team environment, as a better management approach.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices