Durant le développement de masapi, je m'en suis justement servi pour solutionner un problème très joliment. Pour commencer, ma classe se présente comme suit :

package
{
   public class LoadableFileFactory
   {
       public function createLoaderFile(url:URLRequest):ILoadableFile { ... }
       public function createSoundFile(url:URLRequest):ILoadableFile { ... }
       public function createStreamFile(url:URLRequest):ILoadableFile { ... }
       public function createURLLoaderFile(url:URLRequest, dataFormat:String):ILoadableFile { ... }
   }
}

J'en viens maintenant à ajouter une méthode qui en appellera dynamiquement une de ces quatre pour créer un objet ILoadableFile. Afin d'augmenter la modularité, je vais en crééer une autre qui va me renvoyer la fonction à appeler :

public function create(url:URLRequest, type:String):ILoadableFile { ... }
public function getMethod(type:String):Function { ... }

Le type est une constante (issue de la classe LoadableFileType) qui comporte les valeurs suivantes : variables, text, binary, sound, swf, stream. La première implémentation qui vient à l'esprit est celle-ci :

public function create(url:URLRequest, type:String):ILoadableFile
{
   var method:Function = getMethod(type);
   return method(url);
}
 
public function getMethod(type:String):Function
{
     switch(type)
     {
           case "variables":
           case "text":
           case "binary":
              return createURLLoaderFile;
 
           case "sound":
              return createSoundFile;
 
           case "swf":
              return createLoaderFile;
 
           case "stream":
              return createStreamFile;
     }
}

Le problème saute aux yeux : le deuxième paramètre de la méthode createURLLoaderFile ! Etant donné que dans la méthode create, l'appel est dynamique, il semble obligatoire de faire une implémentation du genre :

public function create(url:URLRequest, type:String):ILoadableFile
{
   var method:Function = getMethod(type);
   if (method == createURLLoaderFile) return createURLLoaderFile(url, type);
   return method(url);
}

Cette idée n'est pas bonne, tout simplement car si je veux utiliser ma méthode getMethod dans une autre classe, je vais devoir implémenter ce test à chaque fois. De plus il est très facile d'oublier de le faire... C'est là que la notion de closure intervient !

Au lieu de retourner une référence directe sur la méthode createURLLoaderFile, il suffit de créer une fonction qui passera le paramètre pour nous à celle-ci :

public function getMethod(type:String):Function
{
     switch(type)
     {
           case "variables":
           case "text":
           case "binary":
              return function(url:URLRequest):ILoadableFile
              {
                   return createURLLoaderFile(url, type);
              }
 
           //...
     }
}

Et le tour est joué ! Lorsque je parle du contexte d'exécution, c'est le fait que malgré que la closure retournée par la méthode getMethod puisse être appelée bien plus tard (et dans une autre classe que LoadableFileFactory), elle appellera la méthode createURLLoader de la bonne instance avec les bons paramètres !

Il est également intéressant de noter que la référence du this a été correctement implémentée en AS3. En AS2, il aurait fallut préciser sur quelle instance l'appel createURLLoader est fait (la fameuse astuce du this) :

//code AS2
public function getMethod(type:String):Function
{
     switch(type)
     {
           case "variables":
           case "text":
           case "binary":
              var factory:LoadableFileFactory = this;
              return function(url:URLRequest):ILoadableFile
              {
                   return factory.createURLLoaderFile(url, type);
              }
 
           //...
     }
}

Pour ceux qui aimeraient voir directement l'implémentation dans masapi, c'est par ici !