| By Danny Patterson | Article Rating: |
|
| August 3, 2005 02:15 PM EDT | Reads: |
45,268 |
Design patterns are standardized solutions to common programming problems. It's good to use design patterns for two simple reasons. First, it's faster (and many times better) to implement a time-tested design pattern as opposed to developing a custom solution. Second, collaboration with other developers increases when common practices are used.
The Singleton Pattern
The Singleton design pattern is one of the most widely known design patterns; and it's also one of the simplest. It's used to insure that a class is only instantiated once. The pattern also provides a global point of access to the sole instance of that class. Many classes have to be able to limit their instantiation to a single instance. For example, you may write a focus manager for you application. If you had two instances of the focus manager, they might conflict with each other and create race conditions. So it's essential that you have only one instance per application.
There are two goals for the Singleton pattern: one instance and global access. The global access point insures that all of your classes have access to that single instance. But the main task of the Singleton pattern is to ensure that there is only one instance of the class. That's why the Singleton pattern lets the class manage its own instantiation. Instead of creating an instance of the class by using a new keyword, outside access will be given via a static method that returns the lone instance of the class. If the instance doesn't exist then it creates the instance before returning the reference.
There are two things you must do to make the Singleton pattern work. The first is to use a static method to retrieve the instance of the class and a static property to store the instance. The static keyword indicates that the following method or property is created only once per class rather than being created in every instance of the class.
The second thing you must do is make the constructor private. A private constructor is rare in ActionScript. Since the constructor is private, instantiation can only happen in the class. By making the constructor private, you can insure that no one can instantiate your class outside of the static method.
The Singleton pattern may seem complex, but the code is actually simple. The following example contains all the code you would need to make your class follow the Singleton pattern:
class Singleton {
static private instance:Singleton;
private function Singleton() {}
static public function getInstance():Singleton {
if(instance == undefined) {
instance = new Singleton();
}
return instance;
}
The instantiation of a Singleton class is a little different from a normal class. Normally we'd call the constructor directly like this:
var foo:Singleton = new Singleton();
However, in the Singleton pattern our constructor is private so that code would fail. We must get the single instance of this class by calling the static getInstance method like this:
var foo:Singleton = Singleton.getInstance();
Singleton in Action
In the following example, we'll build a class for tracking the navigation history of a given application. We'll use the Singleton pattern so all of an application's navigational classes track this history information in a central location. An example of some navigational classes might be a menu bar, a link, or even a button. All of these objects will have to be able to track the application's history. But ultimately there can be only one navigation history for an application so we use the Singleton pattern. This class is simple. It will simply store a string to describe a history destination. Any variety of information your application may need to determine the history destination could substitute. Our class will contain one private array that will hold all of the items in our application's history. We will also have an addItem method for adding destination items to the history. Then we'll have previousItem and nextItem methods for going forward and backward in our history.
// History.as
class History {
private var historyItems:Array;
private var currentPosition:Number;
static private var instance:History;
private function History() {
historyItems = new Array();
}
static public function getInstance():History {
if(instance == undefined) {
instance = new History();
}
return instance;
}
public function addItem(item:String):Boolean {
if(item != historyItems[currentPosition]) {
if(currentPosition < (historyItems.length - 1)) {
historyItems = historyItems.slice(0,
(currentPosition + 1));
}
historyItems.push(item);
currentPosition = historyItems.length - 1;
return true;
}
return false;
}
public function get nextItem():String {
if(currentPosition != undefined && currentPosition <
(historyItems.length - 1)) {
return historyItems[++currentPosition];
}else {
return null;
}
public function get previousItem():String {
if(currentPosition != undefined && currentPosition > 0) {
return historyItems[--currentPosition];
}else {
return null;
}
Published August 3, 2005 Reads 45,268
Copyright © 2005 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Danny Patterson
Danny Patterson is a Consultant
specializing in Flash and Web technologies. Danny is a Partner and
Author at Community MX (communitymx.com) and a member of Team Macromedia
Flash. He is a Certified Advanced ColdFusion MX, Flash MX and Flash MX
2004 Developer. You can check out his weblog at DannyPatterson.com.
![]() |
SYS-CON Belgium News Desk 08/03/05 01:41:16 PM EDT | |||
Macromedia Flash - How To Use the Singleton Design Pattern. Design patterns are standardized solutions to common programming problems. It's good to use design patterns for two simple reasons. First, it's faster (and many times better) to implement a time-tested design pattern as opposed to developing a custom solution. Second, collaboration with other developers increases when common practices are used. |
||||
- Cloud Expo New York: Why PostgreSQL is the Database for the Cloud
- Cloud Expo New York Speaker Profile: Dave Linthicum – Blue Mountain Labs
- Agile Adoption – Crossing the Chasm
- Cloud Expo New York: The Java EE 7 Platform - Developing for the Cloud
- Write Once Run Anywhere or Cross Platform Mobile Development Tools
- Cross-Platform Mobile Website Development – a Tool Comparison
- Cloud Expo New York: Cloud Architectures Require Scale-Out Storage
- Cloud Expo New York: The Growing Big Data Tools Landscape
- Architecture Governance – the TOGAF Way
- Big Data – A Sea Change of Capabilities in IT
- Cloud Expo New York: Cloud Computing and Healthcare
- Cloud Expo New York: Mobilizing Enterprise Applications for the Cloud
- Cloud Expo New York: Why PostgreSQL is the Database for the Cloud
- Cloud Expo New York Speaker Profile: Dave Linthicum – Blue Mountain Labs
- Agile Adoption – Crossing the Chasm
- Red Hat Executive Appointed to Technology Services Industry Association (TSIA) Support Services Advisory Board
- Graal, a Dynamic Java Compiler in the Works
- Cloud Expo New York: The Java EE 7 Platform - Developing for the Cloud
- Write Once Run Anywhere or Cross Platform Mobile Development Tools
- Cross-Platform Mobile Website Development – a Tool Comparison
- What Motivates Open Standards in the Cloud?
- Cloud Expo New York: Cloud Architectures Require Scale-Out Storage
- Cloud Expo New York: The Growing Big Data Tools Landscape
- Are You Your Own Worst Enemy?
- The i-Technology Right Stuff
- The Top 150 Players in Cloud Computing
- Who Are The All-Time Heroes of i-Technology?
- Where Are RIA Technologies Headed in 2008?
- Get the Message
- ESB Myth Busters: 10 Enterprise Service Bus Myths Debunked
- i-Technology Viewpoint: Is Web 2.0 the Global SOA?
- i-Technology Viewpoint: Thinking Outside the VC Box
- i-Technology Viewpoint: When to Leave Your First IT Job
- SOA Web Services Edge Conference Coverage on SYS-CON.TV
- SYS-CON.TV's "SOA Web Services" and "Enterprise Open Source" Programs To Air in December
- Five Reasons Why Web 2.0 Matters





















