Singleton is one of the (if not THE) most commonly used/abused design pattern adopted in software development.
Basically it’s used to restrict the instantiation of a class to one object only that can be used safely across application architecture. Its implementation is pretty simple compared to other patterns and it’s very similar for the most of programming languages, but in Objective C it has a slightly different approach due to the lack of “normal constructor” that are instead replaced by alloc/init paradigm.

How it works in Objective C

In Objective C, we can speak more appropriately about the SharedInstance pattern rather than traditional Singleton.
This one is often used in Apple frameworks and differently from its twin brother, it does not explicitly forbid the instantiation of multiple class instances, but it simply provide a class method that will return a shared instance. During the first call to that method the instance will be allocated and the next calls will return the previously object created. So this is a sort of hybrid approach.
A common class that use this pattern is UIApplication which implements a sharedApplication method (which returns the current running application). Differently from Singleton which use getInstance(), in Objective C the corresponding method has not a fixed name but it should start with “shared” followed by the “type” of class (so for UIApplication is “sharedApplication” for MYAmazingManager will be “sharedManager“). Anyway there are several exceptions, for example NSFileManager has a “defaultManager” acting as a sharedInstance accessor that could be renamed “sharedManager“.

Pattern implementation

In my singleton implementations I simply call the accessor “sharedInstance“, in this way I can use a simple pre-compiler macro that automatically synthesize this methods for me.
Even implementation of this pattern may vary and personally I adopted one which is thread-safe and rely on CGD (Grand Central Dispatch), which is an affective C level API provided by Apple in order to handle concurrency.

The implementation of my sharedInstance method is the following (comments explain how it works):

Pattern in action!

SharedInstance pattern is IMO the best way to share data across multiple viewControllers in iOS applications.
One practical example is a data manager to share Core Data stuff such managed object context. I realized my own manager so that I can access this objects anywhere with ease like:

So, this is what I done:

1. I defined an interface IFilter, which declares only one method: apply()
2. I defined a dummy Filter class (which implements IFilter in a basic way just to agree to the interface), that is used as a basic empty filter to decorate. It also has a constant called ALL_VALUES which is used as a wildcard for filters (it’s a simple string with value “*”, which means “all values are allowed”)
3. I defined an abstract AbstractFilterDecorator class
4. I created as many subclass of AbstractFilterDecorator as the filters I need (yes I treat filters as classes not mere functions)

The implementation code is the following:

The filter object is wrapped by decorators which all accepts 2 common arguments: an IFilter reference and an Object representing a value. The DateFilter has a third parameter which is used to configure an internal DateFormatter (from mx.formatters package).
I’m pretty satisfied :)
Uh… and if you are worried about performance, it is fast enough because filter object are created once and then the function assigned to filterFunction is a reference to the resulting decorated filter.

UPDATE:
I realized a very simple example application which can be downloaded here.
This following is the content of the mxml file:

The classes diagram of this pattern is composed by an interface or an abstract class which will define the supertype of the class that will be extended (decorated) by one or more classes implementing the same interface and extending an abstract class which identify these as decorator classes.

A real scenario into which apply this pattern can be a cars store. A car is the base class and the accessories such dvd player, gps, air conditioning and so on, can be thought as decorators. Once decorated, the car (which has a method getPrice() which returns its cost) will get updated by accessories, so calling the getPrice() method will include the price of the “naked” car plus the price of the various accessories installed.

Let’s take a look to the classes…

The interface above will be implemented by all the classes and we will treat the car as an IVehicle not a concrete Car class.
This is our simple Car class:

Now is time to see the decorators (in our scenario the accessories). This is the abstract Accessory class, all accessories will extend it:

In Accessory we can notice that the class encapsulate an object of IVehicle which is passed to the constructor (of course since this class is abstract the object will be passed to the constructor of Accessory’s subclasses). This is the key concept of decorator pattern, all decorators keep a reference of the interface they are going to decorate and this reference is used as the base for methods business logic. Let’s see how:

DVDPlayer is a concrete decorator and it uses the encapsulated IVehicle object in order to provide an extended version of the interface methods (getPrice() and getDescription()). Basically it uses first the reference methods and then it adds some other values.

To use the pattern we will first instantiate a Car object, than we will wrap it with one or more decorators:

The output will be:

Price: 50000 - description: Base car
Price: 50550 - description: Base car, DVD Player
Price: 50875 - description: Base car, DVD Player, GPS System

The order into which we wrap the concrete component (Car) is indifferent (we can add GPSSystem before or after DVDPlayer) and of course despite its readability, we can wrap the Car in a single statement:

In this example I used very simple classes, however in a real implementation we can create more sophisticated decorators which will accept extra arguments beyond the IVehicle reference.

Another thing I learned is that design patterns provide a way to solve problems and simplify application’s modification/extension but each pattern can be implemented in a little different way from a language to another and from a developer to another, the only thing that must be unchanged is the goal of the pattern and how it is used.
One, or maybe the simplest, pattern around is the Singleton pattern, which is even one of the most used, even without be aware of it, we used something similar. In fact, Singleton pattern is used when a class must be instantiated only one time in the application (for example a shopping cart in an e-commerce website) or better when a class must exists as only one and be accessible everywhere through a “common access point” which is for convenience a static method called getInstance().

With Java a singleton implementation should be something like this:

public class ClassicSingleton {

   private static ClassicSingleton instance = null;

   protected ClassicSingleton() {

   }

   public static ClassicSingleton getInstance() {

      if(instance == null) {
         instance = new ClassicSingleton();
      }

      return instance;

   }

}

(I taken the code above from this article on javaworld.com: http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html)

In Actionscript 3, the best implementation (in my opinion) of a Singleton pattern is the following:

package {

    import flash.errors.IllegalOperationError;

    public class SingletonClass {

        private static var instance:SingletonClass = new SingletonClass();

        public function SingletonClass() {

            if (instance != null) {

                throw new IllegalOperationError("SingletonClass can't be instantiated because is a Singleton. Use getInstance() to retrieve a class reference.");

            }

        }

        public static function getInstance():SingletonClass {

            return instance;

        }

    }

}

In this way if we try to call the SingletonClass constructor by using the new operator:

var mySingletonClass:SingletonClass = new SingletonClass();

we will get the error: “SingletonClass can’t be instantiated because is a Singleton. Use getInstance() to retrieve a class reference.”. So, the only and sound way to retrieve our SingletonClass is to use getInstance():

var mySingletonClass:SingletonClass = SingletonClass.getInstance();

Every time we will use getInstance() the same class reference will be returned, avoiding multiple class instantiations.

This is clear and good, but initially I was wondering why to use a method to retrieve the instance, in my own custom implementation I wrote the following code:

package {

    import flash.errors.IllegalOperationError;

    public class AbnormalSingleton {

        private static var created:Boolean;

        public function AbnormalSingleton()    {

            if (!created) {

                created = true;

            } else {

                throw new IllegalOperationError("AbnormalSingleton can't be instantiated again because is a Singleton.");

            }

        }

    }

}

With my AbnormalSingleton the first goal of the Singleton pattern is reached (you can’t get more than one instance), but the pattern has also a second goal: provide a common access point to the reference, and without the getInstance() method, this goal can’t be accomplished, moreover patterns are used to avoid errors and to be used by several developers in a clear manner. So, my idea was not so smart, because you can use the new operator to instantiate the class for the first time with no errors, but the second time you will get an error, the situation is not clear! Instead with the previous example, is immediately evident that we can’t use the class to generate multiple instance.