Voici la liste complète des tutoriaux:
- Part 1
- Part 2
- Part 3
- Part 4
- Part 5

Pour finir, voici 2 autres liens intéressants sur l’Objective C et L’IPhone SDK appréhendés encore par des développeurs Flash, avec une mention particulière pour le premier:
Andy Jacobs – from actionscript to cocoa touch
Big Spaceships Labs – Porting actionscript to iPhone, not magic!

To read and parse this file, you need to make an instance of ApplicationLoader in your application, and call its execute method.

<beans>

</beans>

Un billet qui me permet d’inaugurer la sortie officielle d’AMFPHP 1.0 et saluer Patrick Mineault pour son dévouement.

Pour ceux que ça intéresse, pixlib proposera en révision 23 un puissant configurateur d’application + une suppression totale des dépendances avec le package Luminic et dans une prochaine révision, un package remoting autonome, c’est à dire sans aucune dépendance avec le package mx d’Adobe.

Je vous souhaite une bonne année à tous!

package
{
	import flash.net.NetConnection;
	import flash.net.ObjectEncoding;

	public class RemotingConnection extends NetConnection
	{
		public function RemotingConnection( sURL:String )
		{
			objectEncoding = ObjectEncoding.AMF0;
			if (sURL) connect( sURL );
		}

		public function AppendToGatewayUrl( s : String ) : Void
		{
			//
		}
	}
}

<?xml version="1.0" encoding="utf-8"?>

	<mx:Application xmlns:mx="http://www.macromedia.com/2005/mxml"
					xmlns="*"
					creationComplete="initApplication()">

	<mx:Canvas width="100%" height="100%">
		<mx:TextArea width="100%" height="100%" id="output"/>
	</mx:Canvas>

	<mx:Script>
		<![CDATA[
			import flash.net.Responder;

			public var gateway : RemotingConnection;

			public function initApplication()
			{
				gateway = new RemotingConnection( "http://localhost/flashservices/gateway.php" );
				gateway.call( "HelloWorld.say", new Responder(onResult, onFault), "hello world");
			}

			public function onResult( result : Object ) : Void
			{
				output.text = result;
			}

			public function onFault( fault : Object ) : Void
			{
				output.text = fault;
			}
		]]>
	</mx:Script>

</mx:Application>

Commençons donc par la classe ColorMatrixFilter.

Unique prérequis, qui facilitera la compréhension des exemples AS 2.0: Vous vous êtes déjà familiarisés quelque peu avec l’utilisation du package flash.filters.

• ColorMatrixFilter, de quoi s’agit-il ?

Ce filtre applique une matrice de transformation sur les valeurs de couleur et alpha RGBA de chaque pixel d’une image en entrée pour produire une image résultat avec un nouveau jeu de valeurs.

• Mais qu’est ce qu’une matrice pour commencer ?

Une matrice, c’est un tableau bi-dimensionnel de réels constitué de lignes et colonnes.
Une matrice 4×5 est donc ni plus ni moins un tableau contenant 4 lignes et 5 colonnes.

[	0,	1,	2,	3,	4,
	5, 	6, 	7, 	8, 	9,
	10,	11,	12,	13,	14,
	15,	16,	17,	18,	19	]

• Voici maintenant la formule de base qui permet de recalculer le RGBA d’une image à partir d’une matrice 4×5 de valeurs, c’est à dire en pratique, à partir d’un Array composé de 20 réels indexés de 0 à 19 (comme ci-dessus).

Red = 	(a[0]*Red)  + (a[1]*Green)  + (a[2]*Blue)  + (a[3]*Alpha)  + a[4]
Green = (a[5]*Red)  + (a[6]*Green)  + (a[7]*Blue)  + (a[8]*Alpha)  + a[9]
Blue = 	(a[10]*Red) + (a[11]*Green) + (a[12]*Blue) + (a[13]*Alpha) + a[14]
Alpha = (a[15]*Red) + (a[16]*Green) + (a[17]*Blue) + (a[18]*Alpha) + a[19]

Comme vous pouvez le remarquer, pour calculer la valeur finale de chacun des 4 canaux, on multiplie la valeur d’origine de chaque pixel de l’image par la valeur correspondante de la matrice de transformation et on ajoute au total (si stipulée, c’est à dire non nulle) une valeur offset (située entre -255 et 255), respectivement les valeurs indexées 4, 9, 14 et 19.

• Voici maintenant une matrice d’identité, c’est à dire une matrice carrée, dont tous les composants sont nuls sauf les éléments de la première diagonale qui valent un (on fait ici abstraction de la 5ème colonne, les valeurs offsets).

[1,0,0,0,0,
0,1,0,0,0,
0,0,1,0,0,
0,0,0,1,0];

Faisons le calcul du résultat :

Red = 	(1*Red) + (0*Green) + (0*Blue) + (0*Alpha) + 0
Green = (0*Red) + (1*Green) + (0*Blue) + (0*Alpha) + 0
Blue = 	(0*Red) + (0*Green) + (1*Blue) + (0*Alpha) + 0
Alpha = (0*Red) + (0*Green) + (0*Blue) + (1*Alpha) + 0

On obtient au final: Red = (1*Red)
Green = (1*Green)
Blue = (1*Blue)
Alpha = (1*Alpha)

Autrement dit:
Red = Red
Green = Green
Blue = Blue
Alpha = Alpha

Cette matrice a donc pour particularité d’appliquer aucune transformation sur les valeurs RGBA d’une image. Elle map chacun des composants à sa valeur initiale.
Elle constitue donc en définitive un bon point de départ pour toutes vos expérimentations.

• Nous allons maintenant créer le négatif d’une image. On affecte à chacun des canaux (RGB) sa valeur maximale à laquelle on retranche la valeur initiale de l’image.

[	-1,	0,	0,	0,	255,
	0,	-1,	0,	0,	255,
	0,	0,	-1,	0,	255,
	0,	0,	0,	1,	0]

C’est à dire:
Red = 255 – Red
Green = 255 – Green
Blue = 255 – Blue
Alpha = Alpha

import flash.filters.*;

var negativeTransform:ColorMatrixFilter = new ColorMatrixFilter(
	new Array (
	-1,	0,	0,	0,	255,
        0,	-1,	0,	0,	255,
        0,	0,	-1,	0,	255,
        0,	0,	0,	1,	0
		));

// On applique le filtre à une occurrence en le passant en argument 
// à l'intérieur d'un tableau. 
// Ce tableau représente la liste des filtres à appliquer.

// Le MovieClip sera mis automatiquement en cache bitmap 
// (cacheAsBitmap == true) afin d'être traité comme une image.

mc.filters = [ negativeTransform ];

NB: Si l’array contient plusieurs filtres, l’indexage de ceux-ci n’est pas anecdotique. Il s’agit de l’ordre dans lequel vont être appliqués les différents traitements sur le clip cible.

Après cette entrée en matière, vous disposez maintenant des outils nécessaires pour aborder les différents algorithmes disponibles sur le sujet.

Pour constituer des exemples pratiques en AS 2.0, nous allons partir d’un article qui fait référence dans le domaine:
Matrix Operations for Image Processing par Paul Haeberli.

-Premier exemple:

Converting to Luminance
Pour convertir une image en noir et blanc, on utilise cette matrice:

    float mat[4][4] = {
        rwgt,   rwgt,   rwgt,   0.0,
        gwgt,   gwgt,   gwgt,   0.0,
        bwgt,   bwgt,   bwgt,   0.0,
        0.0,    0.0,    0.0,    1.0,
    };

Où rwgt vaut 0.3086, gwgt 0.6094, et bwgt is 0.0820. This is the luminance vector.

Ce qui nous donne en ActionScript:

import flash.filters.*;

// La luminance, c'est la partie du signal vidéo qui contient les informations 
// concernant l'intensité lumineuse, ou brillance, de chaque point.
// En clair, il s'agit de la trame noire et blanc de l'image.

// Voici les constantes pour la conversion.
// Certaines personnes utilisent les valeurs .299, .587, et .114 du modèle colorimétrique  YIQ.
// Mais Paul Haeberli spécifie bien que les valeurs ci-dessous sont meilleures pour du RGB linéaire.
var rwgt:Number = .3086;
var gwgt:Number = .6094;
var bwgt:Number = .0820;

// Charles A. Poynton conseille (dans le faq colorspace) d'utiliser .212671, .715160 et .072169.

var luminanceTransform:ColorMatrixFilter = new ColorMatrixFilter(
	new Array (
	rwgt,   gwgt,   bwgt,   0.0,   0.0,
        rwgt,   gwgt,   bwgt,   0.0,   0.0,
        rwgt,   gwgt,   bwgt,   0.0,   0.0,
        0.0,   	0.0,    0.0,   	1.0,   0.0
		));

mc.filters = [ luminanceTransform ];

-Deuxième exemple à partir de l’étude d’Haeberli:

Changing Brightness
To scale RGB colors a matrix like this is used:

    float mat[4][4] = {
        rscale, 0.0,    0.0,    0.0,
        0.0,    gscale, 0.0,    0.0,
        0.0,    0.0,    bscale, 0.0,
        0.0,    0.0,    0.0,    1.0,
    };

Où rscale, gscale, et bscale specifient les valeurs offset à appliquer sur les valeurs RGB. On peut utiliser cette matrice pour modifier la balance des couleurs d’une image.

Ce qui nous donne en ActionScript:

import flash.filters.*;

// On utilise directement des valeurs offsets pour ajuster de manière uniforme les valeurs RGB.
function getBrightnessTransform( scale:Number ) : Array
{
	return new Array (
	1.0,	0.0,	0.0,	0.0,   scale,
        0.0,	1.0,	0.0,	0.0,   scale,
        0.0,	0.0,	1.0,	0.0,   scale,
        0.0,	0.0,	0.0,	1.0,   0
		);
}

mc.filters = [ new ColorMatrixFilter( getBrightnessTransform( 100 ) ) ];

-Un dernier exemple pour finir, toujours à partir de l’étude d’Haeberli:

Modifying Saturation
Pour saturer les couleurs RGB, on utilise cette matrice:

     float mat[4][4] = {
        a,      b,      c,      0.0,
        d,      e,      f,      0.0,
        g,      h,      i,      0.0,
        0.0,    0.0,    0.0,    1.0,
    };

Où les constantes de luminances sont dérivées à partir de la valeur de saturation comme montré ci-dessous:

    a = (1.0-s)*rwgt + s;
    b = (1.0-s)*rwgt;
    c = (1.0-s)*rwgt;
    d = (1.0-s)*gwgt;
    e = (1.0-s)*gwgt + s;
    f = (1.0-s)*gwgt;
    g = (1.0-s)*bwgt;
    h = (1.0-s)*bwgt;
    i = (1.0-s)*bwgt + s;

Ce qui nous donne en ActionScript:

import flash.filters.*;

var rwgt:Number = .3086;
var gwgt:Number = .6094;
var bwgt:Number = .0820;

function getSaturationTransform ( sat:Number ) : Array
{

	var rl:Number = rwgt * (1 - sat);
	var gl:Number = gwgt * (1 - sat);
	var bl:Number = bwgt * (1 - sat);

	return new Array (
	rl+sat,	gl,		bl,		0,	0,
	rl,		gl+sat,	bl,		0,	0,
	rl,		gl,		bl+sat,	0,	0,
	0,		0,		0, 		1,	0 );
}

mc.filters = [ new ColorMatrixFilter( getSaturationTransform( 3 ) ) ];

Pour finir, voici quelques liens:

• Colorspace-faq — FAQ about Color and Gamma par Charles A. Poynton.
• Matrix Operations for Image Processing par Paul Haeberli
• Using Flash Player 8 filters for good par Tinic Uro.
• Flash8 source color matrix par Grant Skinner.
• Flash 8: ColorMatrix par Mario Klingemann.

J’espère que ces explications et quelques liens vous donneront envie de passer à l’action, coder vos propres classes et vous lancer dans des expérimentations graphiques inédites.

Ce modèle de conception est assez intuitif. Il s’agit d’encapsuler à l’intérieur d’un objet (plus communément appellé commande) le déroulement d’une action. A chaque fois que je voudrais exécuter cette action à l’intérieur d’une application, il me suffira d’appeller la méthode execute() de mon objet commande.

Commençons par un exemple basique :

class RebootCommand
{
 	public function execute() : Void
 	{
  		trace("reboot my PC");
  	}
}

import RebootCommand;

var oReboot:RebootCommand = new RebootCommand();
oReboot.execute();

La classe RebootCommand une fois instanciée me permet de rebooter mon ordinateur à chaque appel de sa méthode execute.

A partir de ce postulat, il devient évident que pour pouvoir être exécutée, une commande doit obligatoirement implémenter une méthode execute. Cette méthode contiendra les éléments nécéssaires au bon déroulement de l’action sollicitée.

Par conséquent, une commande devra obligatoirement implémenter l’interface suivante :

interface Command
{
 	public function execute() : Void;
}

Reprenons maintenant le même exemple en utilisant l’interface ci-dessus :

import Command;

class RebootCommand implements Command
{
 	public function execute() : Void
 	{
  		trace("reboot my PC");
  	}
}

L’utilisation de l’interface Command : – Garantit que ma commande possède bien une méthode execute pour être déployée. – Permet (comme nous le verrons plus tard) de recourir au polymorphisme pour exécuter des commandes diverses sans se soucier de leur implémentation concrète.

Point essentiel et souvent controversé, la méthode execute ne renvoit rien mais SURTOUT n’autorise aucun paramètre. En effet, une commande, au moment de son exécution est censée déjà détenir les éléments nécessaires pour pouvoir interagir avec le système.

De prime abord, cela peut paraître un peu rigide et vous devez vous demander comment procéder pour spécifier des interactions avec le coeur de l’application ?

Il suffit tout simplement d’utiliser le constructeur de votre classe concrète pour pouvoir stocker les propriétés qui seront nécessaires au moment de l’exécution.

Prenons un deuxième exemple pour illustrer ceci :

import Command;

class DisplayDateCommand implements Command
{
 	private var _tViewHelper:TextField;

 	public function DisplayDateCommand(tViewHelper:TextField)
 	{
  		_tViewHelper = tViewHelper;
  	}

 	public function execute() : Void
 	{
  		_tViewHelper.text = String(new Date());
  	}
}	}
}

Dans l’exemple ci-dessus on utilise un helper en paramètre dans le constructeur pour spécifier la cible graphique qui affichera la date du jour.

Il est biensûr possible d’ajouter des accesseurs dans votre classe concrète pour pouvoir modifier à tout moment les propriétés requises pour l’exécution de votre commande :

import Command;

class DisplayDateCommand implements Command
{
 	private var _tViewHelper:TextField;

 	public function DisplayDateCommand(tViewHelper:TextField)
 	{
  		_tViewHelper = tViewHelper;
  	}

 	public function execute() : Void
 	{
  		_tViewHelper.text = String(new Date());
  	}

 	public function setViewHelper(tViewHelper:TextField) : Void
 	{
  		_tViewHelper = tViewHelper;
  	}
}

import DisplayDateCommand;

this.createTextField("__txt", 1, 30, 30, 200, 20);
var ddc:DisplayDateCommand = new DisplayDateCommand();
ddc.setViewHelper(this.__txt);
ddc.execute();

Maintenant, passons à la question phare, celle que vous êtes tous en droit de vous poser : Quel est l’intérêt de ce modèle de conception ?

L’intérêt majeur, c’est de pouvoir découpler l’objet qui crée une requête pour une action donnée et l’action elle-même ou le receveur de celle-ci. L’exemple récurrent pour illustrer ce concept, c’est l’utilisation d’UIs (interfaces utilisateur) à l’interieur d’une application. Une interface utilisateur est censée ignorer l’implémentation et le déroulement des requêtes qu’elle formule. Autrement dit, le code des requêtes doit donc en aucun cas être exposé à celle-ci. On préférera l’encapsuler à l’intérieur de commandes, classes concrètes implémentant la classe abstraite Command (interface Command en AS2.0). Les UIs n’auront plus qu’à invoquer les commandes disponibles pour obtenir satisfaction à leurs requêtes.

import DisplayDateCommand;
import mx.controls.Button;

this.createTextField("__txt", 2, 30, 30, 200, 20);
var tDisplay:TextField = this.__txt;

var oDdC:DisplayDateCommand = new DisplayDateCommand();
oDdC.setViewHelper(tDisplay);

var pbGetDate:Button = this.createClassObject(Button, "__pbGetDate", 1);
pbGetDate.move(30, 60);
pbGetDate.label = "Display";
pbGetDate.addEventListener("click", this);

function click() : Void
{
 	oDdC.execute();
}

Deuxième aspect non négligeable, c’est la possibilité d’atomiser les fonctionnalités d’une application en objets indépendants pour ne pas surcharger le contrôleur d’une application. On constatera par expérience que niveau design, il est toujours plus facile et élégant de changer par exemple l’implémentation d’une commande SeConnecter à l’intérieur d’une classe dédiée que de parcourir 2.000 lignes de code d’un contrôleur pour modifier celle-ci.

L’atomisation des fonctionnalités peut permettre aussi de créer des classes composites pour définir des macro-commandes (enchaînement de plusieurs commandes).

import Command;

interface MacroCommand extends Command
{
 	public function addCommand(oCommand:Command) : Void;
}

import MacroCommand;

class MyMacroCommand implements MacroCommand
{
 	private var _aCommands:Array;

 	public function MyMacroCommand()
 	{
  		_aCommands = new Array();
  	}

 	public function addCommand(oCommand:Command) : Void
 	{
  		_aCommands.push(oCommand);
  	}

 	public function execute() : Void
 	{
  		var l:Number = _aCommands.length;
  		for (var i:Number = 0; i<l; i++) _aCommands[i].execute();
  	}
}

import MyMacroCommand;
import RebootCommand;
import DisplayDateCommand;

this.createTextField("__txt", 2, 30, 30, 200, 20);

var oMMC:MyMacroCommand = new MyMacroCommand();
oMMC.addCommand( new RebootCommand() );
oMMC.addCommand( new DisplayDateCommand(this.__txt) );

oMMC.execute();

addCommand utilise le polymorphisme d’interface que j’évoquais au début de cet article. Cette méthode attend en paramètre un objet de la famille Command, la nature exacte de celui-ci lui importe peu.

Le dernier aspect est le plus intéressant à mon goût. Il s’agit de déployer le command pattern à l’intérieur d’un front controller pour gagner en souplesse lors du développement et la maintenance d’une application.

Ceci sera le sujet du prochain volet.

Voici pour finir une fiche technique résumant les caractéristiques du modèle Command :

Nom : Command pattern
Le problème :
Découpler les objets qui invoquent une action de ceux qui l’exécutent.
La solution :
Créer une classe abstraite Command (interface) avec une méthode execute. Chaque commande (action) d’une application sera une classe concrète implémentant la méthode virtuelle execute. Les objets qui en feront la requête n’auront plus qu’à trigger celle-ci sans en connaître l’implémentation
Les conséquences :
- Le command pattern éradique tout couplage potentiel entre l’objet qui invoque une opération et celui qui sait comment la réaliser.
- Une commande est un objet à part entière. Elle peut être manipulée, voire même étendue comme bon vous semble.
- On peut créer des commandes composites (cf: MacroCommand).
- Les commandes peuvent offrir la possibilité de faire et défaire (undo et niveaux d’undos).
- Les commandes jugulées à un front-controller offrent à une application une souplesse et une capacité de maintenance indéniables.

Les fichiers sources sont disponibles ici.

Voilà, cet article touche à sa fin. J’ai tenté plus ou moins adroitement de vulgariser ce modèle de conception et de l’illustrer avec des exemples qui restent le plus simple possible afin que tout le monde puisse y trouve son compte. La suite bientôt, avec au programme quelques notions un peu plus avancées cette fois-ci : Création d’un Front Controller déployant le Command pattern avec ViewHelper à l’appui.

Il est possible qu’entre temps je vous fasse d’abord faire un petit détour par le modèle Observer et vous propose une manière qui me semple plus adéquate pour gérer les événements en AS 2.0 que celle proposée par EventDispatcher. (Avis 100% subjectif bien entendu) En effet, la force d‘EventDispatcher c’est sa souplesse, mais c’est malheureusement aussi son talon d’achille. Je déplore son typage faible, son incapacité à scinder les écouteurs en plusieurs groupes (statique oblige) et l’impossibilité de savoir si pour un événement donné un ou plusieurs objets sont abonnés. Ce sera l’occasion pour moi de vous faire découvrir une autre façon de travailler avec les événements (plus rigide) et vous faire partager le package com.bourre.events de pixLib en avant-première.

En attendant n’hésitez pas à me faire partager vos éventuelles questions ou commentaires.

Petit rappel de rigueur, créer une classe abstraite, c’est définir
une classe mère non instantiable qui décrit les comportements
génériques de classes plus spécialisées, les classes concrètes.

Aujourd’hui, nous allons étudier le modèle fabrique abstraite, en
nous servant des notions acquises lors des deux précédents
volets : Singleton et abstract.

Entrons tout de suite dans le vif du sujet !

L’intérêt de la fabrique abstraite, c’est de proposer une interface
pour créer des familles d’objet sans avoir à manipuler directement
leurs classes concrètes.

Quand dois-je avoir recours à ce pattern ? Quand je veux
pouvoir utiliser une famille d’objets et pouvoir la substituer à tout
moment par une autre à l’intérieur de mon application.

Mais qu’est-ce qu’une fabrique ? Une fabrique, c’est une classe
permettant de créer des instances d’une classe ou d’un set de classes.
Son rôle est d’encapsuler la création des dites instances et de servir
(le plus souvent) de référence globale pour la création de celles-ci en
deployant le pattern Singleton.

Pour illustrer ce concept, j’ai repris l’exemple cliché souvent
associé à ce pattern, créer deux famille de widgets et offrir à tout
moment la possibilité de remplacer l’une par l’autre. Mais rien ne vous
interdit de l’appliquer à des domaines totalement différents. Quelques
exemples divers : – Génération des éléments d’un jeu avec des
familles d’objets classées par niveaux de difficulté ou par univers. -
Création d’un environnement skinnable. – Réalisation d’un framework
modulable avec des familles d’objets liées à certaines utilisations
spécifiques. …

Le principe fondamental, c’est de créer une classe abstraite listant
les méthodes communes à chaque fabrique. Ces méthodes une fois
implémentées dans les fabriques concrètes (fabrique de chaque famille)
permettront d’instancier chaque type d’objet spécifique.

// UIsFactory.as

import factory.abstract.ScrollBar;
import factory.abstract.Container;
import factory.abstract.MenuBox;

class factory.abstract.UIsFactory
{
 	public var createScrollBar:Function;
 	public var createContainer:Function;
 	public var createMenuBox:Function;

 	private function UIsFactory() {}

}

// UIsFactoryMethods.as

import factory.abstract.ScrollBar;
import factory.abstract.Container;

import factory.abstract.MenuBox;

interface factory.abstract.UIsFactoryMethods
{
 	public function createScrollBar() : ScrollBar;
 	public function createContainer() : Container;
 	public function createMenuBox() : MenuBox;

}

Les objets sont donc pour l’instant abstraits eux aussi. Ceci nous
permettra plus tard de spécialiser chacun d’eux en corrélation avec la
famille à laquelle ils appartiennent.

// ScrollBar.as

class factory.abstract.ScrollBar
{
 	public var scroll:Function;

 	private function ScrollBar() {}

}

// ScrollBarMethods.as

interface factory.abstract.ScrollBarMethods
{
 	public function scroll() : Void;

}

// Container.as

class factory.abstract.Container
{
 	public var empty:Function;

 	private function Container() {}

}

// ContainerMethods.as

interface factory.abstract.ContainerMethods
{
 	public function empty() : Void;

}

// MenuBox.as

class factory.abstract.MenuBox
{
 	public var display:Function;

 	private function MenuBox() {}

}

// MenuBoxMethods.as

interface factory.abstract.MenuBoxMethods
{
 	public function display() : Void;

}

Je peux donc maintenant créer mes deux familles, Rebound et Water,
avec pour chacune d’elle, une fabrique concrète me permettant
d’instancier mes widgets.

// ReboundUIsFactory.as

import factory.abstract.UIsFactory;
import factory.abstract.UIsFactoryMethods;

import factory.abstract.ScrollBar;
import factory.abstract.Container;
import factory.abstract.MenuBox;

import factory.elastic.ElasticScrollBar;
import factory.elastic.ElasticContainer;
import factory.elastic.ElasticMenuBox;

class factory.ReboundUIsFactory extends UIsFactory implements UIsFactoryMethods
{
 	private static var _oInstance = new ReboundUIsFactory();
 	private function ReboundUIsFactory() {}

 	public static function getInstance() : ReboundUIsFactory { return _oInstance; }

 	public function createScrollBar() : ScrollBar
 	{
  		return new ElasticScrollBar();
  	}

 	public function createContainer() : Container
 	{
  		return new ElasticContainer();
  	}

 	public function createMenuBox() : MenuBox
 	{
  		return new ElasticMenuBox();
  	}

}

//WaterUIsFactory.as

import factory.abstract.UIsFactory;
import factory.abstract.UIsFactoryMethods;

import factory.abstract.ScrollBar;
import factory.abstract.Container;
import factory.abstract.MenuBox;

import factory.liquid.LiquidScrollBar;
import factory.liquid.LiquidContainer;
import factory.classic.ClassicMenuBox;

class factory.WaterUIsFactory extends UIsFactory implements UIsFactoryMethods
{
 	private static var _oInstance = new WaterUIsFactory();
 	private function WaterUIsFactory() {}

 	public static function getInstance() : WaterUIsFactory { return _oInstance; }

 	public function createScrollBar() : ScrollBar
 	{
  		return new LiquidScrollBar();
  	}

 	public function createContainer() : Container
 	{
  		return new LiquidContainer();
  	}

 	public function createMenuBox() : MenuBox
 	{
  		return new ClassicMenuBox();
  	}

}

On remarquera au passage qu’il est facile de modifier le contenu de
chacune des familles, vu que les composants sont tous abstraits. Encore
un des bénéfices de l’abstract. ^^

Voici les classes concrètes des objets instanciés à partir des deux fabriques (familles virtuelles) :

// ClassicMenuBox.as

import factory.abstract.MenuBox;

import factory.abstract.MenuBoxMethods;

class factory.classic.ClassicMenuBox extends MenuBox implements MenuBoxMethods

{
 	public function ClassicMenuBox()
 	{
  		trace(this + " was created");
  	}

 	public function display() : Void
 	{
  		trace(this + " display()");
  	}

 	public function toString() : String
 	{
  		return "ClassicMenuBox";
  	}

}

// ElasticContainer.as

import factory.abstract.Container;
import factory.abstract.ContainerMethods;

class factory.elastic.ElasticContainer extends Container implements ContainerMethods
{
 	public function ElasticContainer()

 	{
  		trace(this + " was created");
  	}

 	public function empty() : Void

 	{
  		trace(this + " empty()");
  	}

 	public function toString() : String

 	{
  		return "ElasticContainer";
  	}
}

// ElasticMenuBox.as

import factory.abstract.MenuBox;

import factory.abstract.MenuBoxMethods;

class factory.elastic.ElasticMenuBox extends MenuBox implements MenuBoxMethods

{
 	public function ElasticMenuBox()
 	{
  		trace(this + " was created");
  	}

 	public function display() : Void
 	{
  		trace(this + " display()");
  	}

 	public function toString() : String
 	{
  		return "ElasticMenuBox";
  	}

}

// ElasticScrollBar.as

import factory.abstract.ScrollBar;
import factory.abstract.ScrollBarMethods;

class factory.elastic.ElasticScrollBar extends ScrollBar implements ScrollBarMethods
{
 	public function ElasticScrollBar()

 	{
  		trace(this + " was created");
  	}

 	public function scroll() : Void

 	{
  		trace(this + " scroll()");
  	}

 	public function toString() : String

 	{
  		return "ElasticScrollBar";
  	}
}

// LiquidContainer.as

import factory.abstract.Container;

import factory.abstract.ContainerMethods;

class factory.liquid.LiquidContainer extends Container implements ContainerMethods

{
 	public function LiquidContainer()
 	{
  		trace(this + " was created");
  	}

 	public function empty() : Void
 	{
  		trace(this + " empty()");
  	}

 	public function toString() : String
 	{
  		return "LiquidContainer";
  	}

}

// LiquidScrollBar.as

import factory.abstract.ScrollBar;
import factory.abstract.ScrollBarMethods;

class factory.liquid.LiquidScrollBar extends ScrollBar implements ScrollBarMethods
{
 	public function LiquidScrollBar()

 	{
  		trace(this + " was created");
  	}

 	public function scroll() : Void

 	{
  		trace(this + " scroll()");
  	}

 	public function toString() : String

 	{
  		return "LiquidScrollBar";
  	}
}

Pour finir, déployons notre système à l’intérieur d’une classe nommée pour l’occasion : UserInterface.

// UserInterface.as

// On importe la fabrique abstraite
import factory.abstract.UIsFactory;

import factory.abstract.ScrollBar;

import factory.abstract.Container;
import factory.abstract.MenuBox;

class factory.UserInterface

{
 	private var _oFactory:UIsFactory;

 	private var _oScrollBar:ScrollBar;
 	private var _oContainer:Container;
 	private var _oMenuBox:MenuBox;

 	public function myUserInterface(oFactory:UIsFactory)

 	{
  		// on stocke une instance de la fabrique concrète spécifiée
  		_oFactory = oFactory;
  		_makeView();
  	}

 	private function _makeView() : Void

 	{
  		// On instancie les objets de la famille choisie (fabrique concrète)
  		_oScrollBar = _oFactory.createScrollBar();
  		_oContainer = _oFactory.createContainer();
  		_oMenuBox = _oFactory.createMenuBox();

  		// On utilise le polymorphisme pour manipuler chacun des objets

  		_oScrollBar.scroll();
  		_oContainer.empty();
  		_oMenuBox.display();
  	}
}

Il ne nous reste plus qu’à lancer l’application en spécifiant la fabrique concrète que l’on veut utiliser, comme ceci :

//

import factory.UserInterface;
import factory.ReboundUIsFactory;
import factory.WaterUIsFactory;

// J'instancie UserInterface en passant en paramètre une instance
// de la fabrique Rebound
trace("ui1:UserInterface >> using ReboundUIsFactory");
var ui1:UserInterface = new UserInterface( ReboundUIsFactory.getInstance() );

// Même chose avec une instance de la fabrique Water
trace("\n" + "ui2:UserInterface >> using WaterUIsFactory");
var ui2:UserInterface = new UserInterface( WaterUIsFactory.getInstance() );

Voici pour finir une fiche technique résumant les caractéristiques du modèle Abstract Factory :

Nom : Abstract Factory
Le problème : Créer une interface pour produire des familles d’objet sans avoir à manipuler directement leurs classes concrètes.
La solution : Utiliser une fabrique abstraite en guise
de patron et créer des fabriques concrètes sur ce modèle. Réaliser une
classe abstraite pour chaque type d’objet et créer des classes
concrètes implémentant leurs spécificités au sein de chaque famille.

Les conséquences :
- On élabore un système qui permet de choisir une famille d’objets parmi plusieurs.
- Ce système est totalement indépendant de la manière dont ses
composants ont été créés, combinés ou sont représentés. Celà facilite
donc la substitution d’une famille par une autre.
- On renforce le couplage au sein d’une famille d’objets afin de les
utiliser par lot. Au résultat, on favorise la cohérence et le maintien
de ceux-ci.

La suite, bientôt !

En attendant n’hésitez pas à me faire partager vos éventuelles questions ou commentaires.

Une classe abstraite est une classe sans implémentation, représentée par des fonctions virtuelles pures (sans code), dont les implémentations sont différées dans les sous-classes.

Mais à quoi sert une classe abstraite ?

Prenons un exemple concret pour commencer, celui d’un jeu de plateformes. Il pourrait être avantageux de définir une classe abstraite MovingSprite qui contiendrait toutes les propriétés et méthodes récurrentes décrivant les fonctionnalités d’un objet animé à l’écran (propriétés : nom, position, taille et méthodes: supprimer, cloner, … ).
Nous prendrions soin aussi de définir des méthodes abstraites, méthodes qui seraient obligatoirement implémentées par les classes dérivées et qui permettraient à celles-ci d’exprimer leurs spécificités (bouger, disparaitre, immobiliser … ).

En résumé, une classe abstraite sert à fournir un modèle générique qui ne sera pas instancié mais juste étendu, une sorte de patron numérique.
L’implémentation de ses méthodes abstraites par les classes dérivées permettra de faire du polymorphisme d’héritage. On pourra par exemple passer en revue à l’intérieur d’une boucle toutes nos instances des classes dérivées de MovingSprite et invoquer indifféremment sur chacune d’elles la méthode bouger.

Une classe abstraite doit donc répondre à deux exigences :
- Elle ne peut être instanciée.
- Ses méthodes abstraites doivent être obligatoirement implémentées par les classes dérivées.

Le mot-clef abstract n’existe pas en ActionScript 2.0. Pour coller au concept, j’ai donc recours à un subterfuge au niveau design. Pour ce faire, j’utilise une classe doublée d’une interface.
Le constructeur de la classe est mis en private pour interdire l’instanciation et l’interface contient toutes les méthodes abstraites de la classe.
Une classe concrète voulant hériter d’une classe abstraite devra donc étendre celle-ci et implémenter l’interface contenant ses méthodes abstraites.
Dernier point important, la classe devra déclarer (en attributs) toutes les méthodes abstraites afin de permettre le polymorphisme.

Voici un exemple simple illustrant le déploiement de cette architecture :

class shapes.abstract.Shape

{
 	private var _nColor:Number;

 	// On déclare les noms de méthodes abstraites pour permettre le polymorphisme
 	public var getArea:Function;

 	// Le constructeur est privé pour empêcher l'instanciation

 	private function Shape() {}

 	// Méthode non abstraite de la classe
 	public function setColor(nColor:Number)

 	{
  		_nColor = nColor;
  	}
}

interface shapes.abstract.ShapeMethods
{
 	// Liste des méthodes abstraites de la classe Shape.

 	// Toutes les classes concrètes devront implémenter
 	// les méthodes listées.
 	public function getArea() : Number;

}

// import des deux classes pour émuler le concept abstract
import shapes.abstract.Shape;
import shapes.abstract.ShapeMethods;

 
// Rectangle hérite de Shape et doit implémenter ses méthodes
// en respectant le typage.
class shapes.Square extends Shape implements ShapeMethods

{
 	private var _nSide:Number;

 	public function Square(nSide:Number)
 	{

  		_nSide = nSide;
  	}

 	// La méthode abstraite getArea est implémentée comme spécifié dans l'interface
 	public function getArea() : Number
 	{

  		return _nSide * _nSide;
  	}

 	public function toString() : String { return "Square"; }

}

// import des deux classes pour émuler le concept abstract
import shapes.abstract.Shape;
import shapes.abstract.ShapeMethods;

 
// Circle hérite de Shape et doit implémenter ses méthodes
// en respectant le typage.
class shapes.Circle extends Shape implements ShapeMethods

{
 	private var _nRadius:Number;

 	public function Circle(nRadius:Number)
 	{

  		_nRadius = nRadius;
  	}

 	// La méthode abstraite getArea est implémentée comme spécifié dans l'interface
 	public function getArea() : Number
 	{

  		return 2 * _nRadius * Math.PI;
  	}

 	public function toString() : String { return "Circle"; }

}

// import des deux classes pour émuler le concept abstract
import shapes.abstract.Shape;
import shapes.abstract.ShapeMethods;

 
// Rectangle hérite de Shape et doit implémenter ses méthodes
// en respectant le typage.
class shapes.Rectangle extends Shape implements ShapeMethods

{
 	private var _nWidth:Number, _nHeight:Number;

 	public function Rectangle(nWidth:Number, nHeight:Number)
 	{

  		_nWidth = nWidth;
  		_nHeight = nHeight;
  	}

 	// La méthode abstraite getArea est implémentée comme spécifié dans l'interface
 	public function getArea() : Number
 	{

  		return _nWidth * _nHeight;
  	}

 	public function toString() : String { return "Rectangle"; }

}

// On importe la classe abstraite
import shapes.abstract.Shape;
 
class shapes.ShapesManager

{
 	// container pour stocker les objets
 	private static var _aShapes:Array = new Array();

 	// Surface totale des objets agrégés dans le manager

 	public static var totalArea:Number = 0;

 	// Méthode pour ajouter un objet au manager
 	// On s'assure grâce au typage fort qu'il s'agit bien d'un objet Shape

 	public static function addShape(s:Shape)
 	{
  		// On ajoute l'objet au tableau
  		_aShapes.push(s);
  		// On peut faire du polymorphisme

  		totalArea += s.getArea();
  	}

 	// Méthode pour supprimer un objet du manager en fournissant son id

 	public static function removeShape(nID:Number) : Void

 	{
  		// On vérifie que l'ID est bien valide
  		if (nID>=_aShapes.length || nID < 0) throw new Error("error, wrong ID !");

  		// On réactualise la valeur de la surface totale

  		totalArea -= _aShapes[nID].getArea();

  		// On supprime l'objet
  		delete _aShapes[nID];
  	}
}

// test.fla
 
// Import du package
import shapes.*
 
// Ajout des formes
ShapesManager.addShape( new Rectangle(5, 10) );
ShapesManager.addShape( new Square(5) );
ShapesManager.addShape( new Circle(6) );

 
// Sortie de la surface totale
trace( ShapesManager.totalArea );
 
// Suppression du rectangle
ShapesManager.removeShape(2);
 

// Sortie de la surface totale
trace( ShapesManager.totalArea );

La suite ce week-end avec le modèle fabrique abstraite.

En attendant n’hésitez pas à me faire partager vos éventuelles questions ou commentaires.

Voici enfin aujourd’hui la première partie, chargée d’introduire les modèles de création et d’exposer au grand jour le pattern Singleton.

Une petite mise en garde de rigueur avant de commencer :

Pour aborder cette série d’articles, il est indispensable que vous possédiez déjà des connaissances de base en programmation orientée objet.

Maîtriser la syntaxe ActionScript 2.0 sera biensûr un atout majeur qui vous permettra de décortiquer les exemples donnés tout au long des différents dossiers.

En dernier préambule, j’aimerai insister aussi sur le fait que la plupart des patterns prennent vraiment tout leur sens lorsqu’ils sont employés à l’intérieur de véritables applications ou plutôt … Laissez moi reformuler ma phrase : L’intérêt de chaque pattern devient évident et limpide lorque l’on s’est déjà heurté au problème dont il se propose d’être le remède. Pour résumer, c’est quand on commence à se confronter aux réelles difficultés liées au développement que ces élégantes abstractions deviennent limpides. Il est en effet souvent très difficile (voir impossible) de cultiver la robustesse, la sécurité, la durabilité ou l’évolutivité du code sans recourir à toutes ces bottes secrètes. Cet apprentissage (comme la plupart) peut biensûr se dérouler de façon totalement intuitive tout au long des expériences de chacun. Passer par la théorie c’est se donner des chances supplémentaires de voir clair vite et bien.

En général un modèle de conception se décompose en quatre parties :

- Le nom

- Le problème

- La solution

- Les conséquences

Ces caractéristiques portent des noms assez explicites pour m’éviter la rédaction inutile d’un glossaire pompeux et redondant. Si tel n’était pas le cas, je reste persuadé que les explications qui suivront vous aideront à mettre en lumière leur vocation respective.

La première famille de modèles que nous allons donc aborder est spécialisée dans la création, comprenez par là : Processus d’instanciation.

Il s’agit des modèles créateurs.

L’intérêt majeur de cette famille, c’est de privilégier l’abstraction d’un processus de création plutôt que de coder celui-ci en dur et se heurter par là même (tôt ou tard) à une inertie écrasante du système, que je qualifierai (avec humour) de fossilisation irréversible de l’application.

Pour prendre une image du monde réel (encore une), il est plus facile en tant que patron d’un hôtel d’employer un cuisinier pour répondre à l’attente de ses clients concernant leur appétit et goûts respectifs, plutôt que de laisser la possibilité à chacun de se restaurer en mettant à disposition locaux, ustensiles recettes et provisions de l’établissement. Il n’est pas besoin d’être un savant informaticien pour cerner les problèmes de logistique engendrés par la deuxième solution.

Offrir la reponsabilité à une entité de s’occuper de la création de chaque plat en s’adaptant à la demande de notre aimable clientèle ainsi qu’aux contraintes imposées par le système (stock, coûts …) nous permet non seulement d’occulter la fabrication des plats mais aussi d’interchanger le détenteur de cette responsabilité selon nos besoins ou exigences (grand chef cusinier pour les soirées V.I.P contre équipe d’apprentis pour les grands rushs de midi).

Pour résumer, le principe fédérateur de cette famille de patterns, c’est d’encapsuler la connaissance des classes concrètes (recette de chaque plat) que le système (hôtel) utilise et masquer le déroulement et le paramétrage d’une instanciation (fabrication d’un plat).

Pour commencer, voici la liste des patterns appartenant à cette famille de modèles (modèles créateurs) :

- Fabrique abstraite

- Monteur

- Fabrication

- Prototype

- Singleton

Nous allons commencer cette étude par un patterns très utilisé, j’ai nommé le Singleton.

Il est souvent important au sein d’une application de pouvoir s’assurer premièrement de l’unicité d’un objet, deuxièmement de son accessibilité à tout moment par les autres objets de l’application sans avoir recours à des références multiples.

Comme un exemple est souvent beaucoup plus parlant qu’une longue explication technnique, nous allons illustrer l’utilisation de ce pattern en nous appuyant sur une situation concréte. Pour les besoins de cette démonstration nous allons créer une classe abstraite Connection dont le rôle sera de créer une connexion socket entre le client Flash et un serveur unique prédéfini.

Vous conviendrez au vu de l’énoncé qu’il serait maladroit voir catastrophique d’avoir des instances multiples de Connection.

En utilisant le pattern Singleton sur notre classe Connection nous garantissons le fait qu’il ne peut y avoir qu’une seule instance de connexion dans notre application.

Cerise sur le gâteau ce pattern fournira un point d’accès unique et global à tous les éléments de notre application nécessitant les services de celle-ci.

// Classe fictive pour illustrer le déploiement du pattern Singleton

class Connection
{
 	// Membre statique protected (faute de pouvoir être placé en privé)
 	// servant à stocker une référence de notre connection, .
 	private static var _oInstance:Connection;

 	// Le constructeur est placé en protected.
 	// Ceci garantit déjà l'impossibilité d'instancier directement une connection
 	// sans passer par le point d'accès.
     private function Connection()
 	{
  		trace("Constructeur appelé");
  	}

 	// L'unique point d'accès qui empêche toute duplication.
     public static function get instance() : Connection
     {
  		// Pour créer une connection (instance de Connection)
  		// On s'assure que celle-ci n'existe pas déjà.
  		if (_oInstance == undefined) _oInstance = new Connection();
  		// Dans tous les cas, on retourne une référence vers l'objet
  		// à celui qui en a fait la demande.
  		return _oInstance;
      }

 	// On prévoit une méthode pour détruire notre instance
 	// en cas de besoin de réinitialisation
 	// ou de libération de la mémoire.
 	public static function release() : Void
 	{
  		// Si l'instance existe on la détruit.
  		if (_oInstance)
  		{
   			trace("instance détruite");
   			delete _oInstance;
   		}
  	}

 	// Maintenant que le pattern est déployé voici le coeur
 	// de notre objet exposé avec ses différentes méthodes :
 	public function connect() : Void {}
 	public function disconnect() : Void {}
}

Note : Le fait que le player Flash ne gére pas le muti-threading nous protège des soucis d’initialisation différée comme dans certains langages comme C++.

La question légitime que l’on est maintenant en droit de se poser face au modéle Singleton c’est pourquoi ne pas passer en statique toutes les méthodes comme je le fais avec la SoundFactory ?

Les deux seuls avantages en ActionScript à retirer sont :

- D’avoir plusieurs instances d’une classe mère par extensions multiples. – D’avoir la possibilité en cours de développement de modifier le design parceque l’on s’aperçoit que l’on nécessite finalement plusieurs instances de la même classe.

Voici pour finir une fiche technnique pour résumer les caractéristiques du modèle Singleton :

Nom : Singleton

Le problème : S’assurer de l’unicité de l’instance d’une classe

La solution :

- Définir un membre privé static pour stocker l’instance.

- Définir une méthode publique pour accéder à celle-ci.

- Mettre le constructeur en protected (private en AS 2.0).

Les conséquences :

- Contrôle d’accès à l’instance régulé.

- Changement de stratégie possible à tout moment.

Et pour accompagner ce résumé voici une implémentation générique du pattern Singleton en ActionScript 2.0 :

class Singleton
{
 	private static var _oInstance:Singleton;

     private function Singleton() {}

     public static function getInstance() : Singleton
     {
  		if (_oInstance == undefined) _oInstance = new Singleton();
  		return _oInstance;
      }

 	public static function release() : Void
 	{
  		if (_oInstance) delete _oInstance;
  	}
}

Le prochain article traitera du modèle fabrique abstraite. En attendant n’hésitez pas à me faire partager vos éventuelles questions ou commentaires.

Les fichiers source sont disponibles ici.

Dans les mois qui viennent je vous propose de vous faire partager mes expérimentations concernant l’implémentation des design patterns en ActionScript2.0.

… Générique …

Mais commençons par le commencement, les design patterns c’est quoi ?

Les modèles de conception sont des solutions simples et élégantes à des problèmes spécifiques de conception de logiciels orientés-objet. (Design patterns – GOF)

Il s’agit donc en résumé, de décrire un fonctionnement et le rendre générique pour qu’il soit toujours réutilisable dans les mêmes circonstances.

J’imagine que cela ne doit pas être très limpide pour tous ceux qui n’ont jamais eu l’occasion d’aborder le sujet. Je vais donc tenter d’illustrer et vulgariser cette définition un peu solennelle en vous offrant une jolie métaphore (un peu tirée par les cheveux certes) en guise d’exemple.

Je suis réalisateur d’une émission de télévision dont le thème principal est l’Europe. Si si c’est vrai, je vous assure ! Chaque semaine, je reçois deux invités venant des quatre coins du continent. Problème récurrent : Mes deux invités ne parlent pas la même langue, difficile donc de les faire s’entretenir sur un sujet donné une heure durant. Pour éviter que mon talk-show ressemble à une tour de Babel cathodique, je vais pour l’occasion recourir à un design pattern éprouvé par tous les médias internationaux. C’est un pote responsable de l’information sur CNN qui me l’a conseillé. Il s’agit du modéle : Traduction simultanée. Solution : Embaucher un interpréte qui s’occupera en temps réel de réaliser les traductions qui seront retransmises à chaque intervenant par le biais d’une oreillette. Avouez que c’est super ingénieux !

Chaque fois donc, qu’une émission veut permettre à deux invités de nationalités différentes de communiquer sans difficulté, elle va recourir au design pattern Traduction simultanée. Il s’agit d’un modéle qui a fait ses preuves au fil des ans et permet ainsi de gagner du temps et de l’énergie dans la réalisation des programmes TV du monde entier.

En grossissant le trait, un design pattern est donc ( comme l’illustre l’exemple ci-dessus ) une solution standard permettant à un réalisateur TV (ou un développeur orienté objet ) de se sortir d’affaires dans un cas donné (souvent assez spécifique) sans qu’il ait à avoir à réinventer la roue à chaque représentation de celui-ci.

Pour utiliser quelques synonymes évocateurs faits maison et enfoncer le clou, je qualifierai un modéle de conception de : Recette miracle, moule conceptuel, empreinte ou même carte aux trésors permettant d’arriver à ses fins à chaque répétition d’une situtation spécifique.

Fin de l’épisode pilote, la prochaine fois je démarrerai la première saison (première famille de modèles) en traitant des modèles créateurs. Le suspens est à son comble ! ^^

… Générique …

Je vous propose de partager aujourd’hui la solution que j’utilise. Elle vous permettra de gérer les profondeurs sans bug d’affichage dans un moteur 3d isométrique animé.

Le concept récurrent pour gérer la profondeur d’un objet dans un tileworld isométrique est d’assigner un z-sorting incrémenté de gauche à droite sur l’axe des x, puis de bas en haut sur l’axe des y comme indiqué sur le schéma ci-dessous :

Ce système fonctionne à merveille tant que l’on se contente du fait que chaque objet se trouvant à une position (x,y) se déplacera sur une case voisine d’un seul jet, sans interpolation de mouvement, autrement dit sans se trouver à un instant t à cheval entre deux cases.
Pourquoi me direz vous ?

Considérons l’exemple ci-dessous :

Un personnage se trouvant à la position 1,1 et voulant se rendre à la position 1,0 va devoir choisir son camp. S’il garde 4 comme profondeur le temps de l’animation pour se rendre sur la case destination, il va passer devant l’objet qui se trouve en 2,0.

S’il choisit de prendre directement sa profondeur d’arrivée (1), il sera le temps de son trajet affiché derrière l’objet se trouvant en 2,0.

On est confronté au même probléme dans le sens inverse comme vous pouvez le remarquer :

La plupart des moteurs utilisant ce système réussissent à tricher en jouant sur la taille des objets à l’intérieur des cases et sur l’instant ou la valeur z-sorting de l’objet en mouvement est modifiée. Mais ces solutions au bout du compte ne sont vraiment pas satisfaisantes pour gérer l’affichage de façon propre et logique.

D’où l’idée d’opter pour une organisation comme celle-ci, avec un z-sorting incrémenté en diagonales :

Cette fois-ci les animations sur l’axe des y peuvent-être gérées sans bug d’affichage :

Mais les esprits judicieux auront remarqué que le probléme est maintenant répercuté sur l’axe des x :

Sans plus attendre, voici la solution finale, le même tableau mais avec des intervalles en dizaine :

Hum … Quoi de mieux me direz-vous ?
L’idée est d’incrémenter de 15 la profondeur d’un personnage voulant se déplacer vers la droite sur l’axe des x (50 dans l’exemple devient 65) et de lui donner à la fin de son parcours la profondeur de la case d’arrivée (80 dans l’exemple ci-dessous) :

Même chose dans l’autre sens, on enléve 15 à la profondeur d’un personnage voulant se déplacer vers la gauche sur l’axe des x (50 devenant 35 dans le cas précis) et on lui attribue à la fin de son trajet la profondeur de la case destination (il passe donc de 35 à 20 en profondeur une fois arrivé) :

Dernier point, quelle méthode utiliser pour calculer la profondeur d’un objet en connaissant la largeur et la hauteur de la grille ainsi que sa position x et y ?
C’était le sujet d’un précédent thread, et je remercie Didier d’avoir trouvé une solution très élégante et rapide pour gérer cette problématique.
Voici le code que j’utilise :

 private function _sum(n:Number) : Number {

         return (n * (n + 1) / 2);
    }
 
   public function calculDepth(x:Number, y:Number) {

         var r:Number = _sum(x + y) + x + 1;
         r = ((x + y) > (grid.x-1)) ? r -= _sum(x + y - (grid.x-1)) : r;
         r = ((x + y) > grid.y) ? r -= _sum(x + y - grid.y) : r;
         return (r*10);
    }

Voila, j’espère que le concept que j’ai développé et utilise couramment pourra contribuer à remplir un peu le vide auquel je me suis confronté lors de mes investigations sur le sujet.

Je tiens à remercier tout particulièrement Joan pour ses idées et Didier pour son algorithme de calcul remarquable ainsi que Jean-Louis pour la conversion en AS.
Comme d’habitude, vos questions, commentaires ou critiques sont les bienvenue.