So let me introduce the first one.
I needed a multi-users game server. So after some googling to browse OS projects, I decided to build a new one from scratch with Apache Mina 2.0 using my R&D xp.
I choosed to install Ubuntu with Parallels to have an easy workflow with a local test workstation.

At this time, I’ve obtained something basic which works fine. That’s full AMF (using BlazeDS ) and it manages users and rooms.
That’s all based on simplicity. No events, no verbosed implementation or mess with abstract design…

My next step and goals:
- Have something robust.
- Build a graphical chat showcase with text to speech feature.
- Build a game showcase with realtime synchronicity. I read a lot of resources about it, and I’m looking forward to work on this.

But I’m wondering about few things at this time:
- Should I go to open source ?
- Should I mix this implementation with Darkstar project ?
- Should I work on a cheap product ?
Any advice would be welcome !

Here’s a basic echo demo to end this thread and showcase the concept:

import net.tweenpix.pixserver.amf.AMFClient;

	public class EchoAMFClient
	{
		protected var _client : AMFClient;

		public function EchoAMFClient()
		{
			_client = new AMFClient( );
			_client.registerClass( TestVO );
			_client.connect( "10.211.55.4", 9123 );

			_client.addEventListener( "EchoMessage",  onEchoMessage );
			_client.sendRequest( 	"EchoMessage",
								new TestVO( "francis", 38 ),
								new TestVO( "virginie", 35 ) );
		}

		public function onEchoMessage( vo1 : TestVO, vo2 : TestVO ) : void
		{
			// do something
		}
	}

You have to make direct method calls on the client (as you would with JavaScript library). It returns a responder instance on each call:

var responder : EventDispatcher = client.Friends.get() as EventDispatcher;

To get some request results, you can suscribe listeners (as many as you want) to any responder:

responder.addEventListener(FacebookClientEvent.ON_RESULT, onFriends);
responder.addEventListener(FacebookClientEvent.ON_FAULT, onError);

And guess what, results are encapsulated in events passed as arguments to your callback methods:

public function onFriends( e : FacebookClientEvent ) : void
{
	trace ( e.methodName + " call: " + e.result.length );
}

Clean and easy as I like it.
Last but not least, you got some errors reporting. I had hard time on this part, coz the JS implementation was acting weird. I’m not even sure at this time to have understood the whole error process. I must finalize this part, few errors aren’t caught at this time but every transaction is logged in firebug with Debug.dump JS calls.

public function onError( e : FacebookClientEvent = null ) : void
{
	trace ( "onGetInfoError(" + "method:" + e.methodName
				+ ", error_code:" + e.result.error_code
				+ ", error_msg:" + e.result.error_msg + ")" );
}

Here’s a short demo to end the teasing around this project.
In this example, client retrieves all the name and profile photos urls of a user friends list through 2 API calls.

package
{
	import com.bourre.facebookflashapi.FacebookClient;
	import com.bourre.facebookflashapi.FacebookClientEvent;

	import flash.display.Sprite;
	import flash.events.EventDispatcher;

	public class FacebookClientTest
		extends Sprite
	{
		protected var client : FacebookClient;

		public function FacebookClientTest()
		{
			client = new FacebookClient();

			var responder : EventDispatcher = (client.Friends.get() as EventDispatcher);
			responder.addEventListener(FacebookClientEvent.ON_RESULT, onFriends);
			responder.addEventListener(FacebookClientEvent.ON_FAULT, onError);
		}

		public function onError( e : FacebookClientEvent = null ) : void
		{
			trace ( "onGetInfoError(" + "method:" + e.methodName
						+ ", error_code:" + e.result.error_code
						+ ", error_msg:" + e.result.error_msg + ")" );
		}

		public function onFriends( e : FacebookClientEvent ) : void
		{
			trace ( e.methodName + " call" );

			( client.users.getInfo( {uids:e.result, fields:["name", "pic_big"]} )
			as EventDispatcher).addEventListener(FacebookClientEvent.ON_RESULT, onGetInfo);
		}

		public function onGetInfo( e : FacebookClientEvent ) : void
		{
			for each ( var o : Object in e.result )
				trace ( "Nom:" + o.name + ", Image:" + o.pic_big );
		}
	}
}

I will release the source code under an open source licence when it’ll be a bit more polished for people who want to try it, and maybe I’ll make a video tutorial, who knows !

Comme la librairie de GreenSock, cette librairie est déclinée en 2 versions. D’un côté la version complète, de l’autre la version light pour les projets à haute contrainte de poids comme les bannières publicitaires.

Shane McCartney nous vante les prouesses de sa librairie en matière de performances avec preuve à l’appui: « J’ai réussi à rendre Tweensy plus rapide que l’ancien tenant du titre AS3: TweenLite/TweenMax. »

Il n’est pas en reste non plus concernant la puissance de l’API de son bébé: « Mais ne pensez pas que Tweensy est juste un moteur de tween efficace de plus, il est aussi conçu pour rivaliser (dépasser à mon humble avis) n’importe quel moteur de tween AS3 existant. S’il manque quelque chose, n’hésitez pas à le demander. »

Concernant cette partie, j’avoue avoir été assez bluffé par l’étendue des possibilités disponibles. La documentation et certaines parties du wiki permettent de se faire une idée du potentiel mis en oeuvre.

En résumé, une librairie à tester de toute urgence pour voir ce qu’elle a dans le ventre en cas pratique !

Via lostinactionscript.com

No tricks deployed this time to optimize Flash rendering. That’s a standard implementation.

[kml_flashembed movie="http://www.tweenpix.net/files/fire.swf" width="450" height="175"/]

Here’s the source code. Enjoy !

package
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageQuality;
	import flash.display.StageScaleMode;
	import flash.events.Event;
	import flash.filters.BlurFilter;
	import flash.geom.Point;
	import flash.geom.Rectangle;

	[SWF( width="450", height="175", frameRate="25" , backgroundColor="0x000000")]
	public class Fire
		extends Sprite
	{
		protected const w : int = 450;
		protected const h : int = 175;

		protected var bd : BitmapData;
		protected var p : Point;
		protected var rect : Rectangle;
		protected var blur : BlurFilter;

		protected var palette : Vector.;
		protected var fire : Array;

		public function Fire()
		{
			stage.scaleMode = StageScaleMode.NO_SCALE;
			stage.align = StageAlign.TOP_LEFT;
			stage.quality = StageQuality.LOW;

			p = new Point(0, 0);
			rect = new Rectangle( 0, 0, w, h );
			blur = new BlurFilter( 4, 4, 1 );
			bd = new BitmapData( w, h, false, 0xFFFFFF );
			addChild( new Bitmap( bd ) );

			var x : int, y : int;
			palette = new Vector.( 256, false );
			fire = [];
			for ( x = 0; x < w; x++ ) fire[x] = new Vector.( h, false );
		    for ( x = 0; x < w; x++ )
		    	for ( y = 0; y < h; y++ )
					fire[x][y] = 256;
			for ( x = 0; x < 256; x++ )
				palette[x++] = HSLtoRGB( x/(3 * 256), 1, Math.min( 256, x * 2 )/256 );

			addEventListener( Event.ENTER_FRAME, enterFrame );
		}

		protected function enterFrame( e : Event ) : void
		{
			bd.lock();
			var x : int, y : int;
		    for ( x = 0; x < w; x++ ) fire[x][h - 1] = Math.random()*32768 % 256;
		    for ( y = 0; y < h - 1; y++ )
    			for ( x = 0; x < w; x++ )
			      fire[x][y] = ((fire[(x - 1 + w) % w][(y + 1) % h]
					+ fire[(x) % w][(y + 1) % h]
			        + fire[(x + 1) % w][(y + 1) % h]
			        + fire[(x) % w][(y + 2) % h]) * 32) / 129;
		    for ( x = 0; x < w; x++ )
			    for ( y = 0; y < h-1; y++ )
			    	bd.setPixel( x, y, palette[fire[x][y]]);
			bd.applyFilter( bd, bd.rect, p, blur );
			bd.unlock();
		}

		public static function HSLtoRGB( h :Number, s : Number , l : Number ) : Number
		{
		    var r : Number = 0, g : Number = 0, b : Number = 0, v1 : Number, v2 : Number;
		    if ( s == 0 )
		    {
		       r = l * 255;
		       g = l * 255;
		       b = l * 255;

		    } else
		    {
		       v2 = ( l < .5 ) ? l * ( 1 + s ) : ( l + s ) - ( s * l );
		       v1 = 2 * l - v2;
		       r = 255 * HueToRGB( v1, v2, h + ( 1 / 3 ) );
		       g = 255 * HueToRGB( v1, v2, h );
		       b = 255 * HueToRGB( v1, v2, h - ( 1 / 3 ) );
		    }
		    return ((r << 16)|(g << 8)|b);
		}

		private static function HueToRGB( v1 : Number, v2 : Number, vH : Number ) : Number
	    {
		    if ( vH < 0 ) vH += 1;
		    if ( vH > 1 ) vH -= 1;
		    if ( ( 6 * vH ) < 1 ) return ( v1 + ( v2 - v1 ) * 6 * vH );
		    if ( ( 2 * vH ) < 1 ) return ( v2 );
		    if ( ( 3 * vH ) < 2 ) return ( v1 + ( v2 - v1 ) * ( ( 2 / 3 ) - vH ) * 6 );
	    	return ( v1 );
		}
	}
}

Merci à Ed Mc Manus pour ce joli travail !
Dommage que Scott Petersen n’ait jamais publié la version qu’il utilise dans ses différents portages (Quake, émulateur Nintendo…).

Inspiration finally came, and I had good time producing some little experiments to play with.
Here’s one of them that I’m glad to share with you.
That’s two animated plasmas mixed together using same color palette. Color palette is splitted in 3 collections, one for red channel, another for green. Blue is unused. The last one is for handling pixels transparency.

[kml_flashembed movie="http://www.tweenpix.net/files/plasma.swf" width="400" height="400"/]


Some optimizations tricks deployed to get display smoothness:
- Plasmas are mixed together without blending. I’m drawing one pixel of each (with boolean checker) while generation.
- I use ByteArray (as video ram like low-level languages do) with BitmapData.setPixels for rendering. I discover it’s faster to not compute each channel if you don’t need it.
- As often, few as3 optimizations tips (Vector collections, int indexes, binary shifting for arithmetical operations, while loop without coordinates…)

Here’s the source code. Enjoy !

package
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageQuality;
	import flash.display.StageScaleMode;
	import flash.events.Event;
	import flash.filters.BlurFilter;
	import flash.geom.Point;
	import flash.geom.Rectangle;
	import flash.utils.ByteArray;

	[SWF( width="400", height="400", frameRate="25" , backgroundColor="0x000000")]
	public class Plasma
		extends Sprite
	{
		protected const w : int = 400;
		protected const h : int = 400;

		protected var bd : BitmapData;
		protected var ba : ByteArray;
		protected var position : uint;
		protected var p : Point;
		protected var rect : Rectangle;
		protected var shifter : int;
		protected var blur : BlurFilter;

		protected const A : Vector. = new Vector.( 256, true );
		protected const R : Vector. = new Vector.( 256, true );
		protected const G : Vector. = new Vector.( 256, true );
		protected var plasma : Vector.;

		public function Plasma()
		{
			stage.scaleMode = StageScaleMode.NO_SCALE;
			stage.align = StageAlign.TOP_LEFT;
			stage.quality = StageQuality.LOW;

			ba = new ByteArray();
			p = new Point(0, 0);
			rect = new Rectangle( 0, 0, w, h );
			bd = new BitmapData( w, h, true, 0 );
			blur = new BlurFilter( 4, 4, 1 );
			addChild( new Bitmap( bd ) );

			// generate palette
			var i : int = 256;
			while( --i > - 1 )
    		{
    			A[i] = int(128 + 128 * Math.sin( 3.1415 * i / 32));
        		R[i] = int(128 + 128 * Math.sin( 3.1415 * i / 16));
        		G[i] = int(128 + 128 * Math.sin( 3.1415 * i / 64));
    		}

    		// generate plasma
    		var x : int, y : int, l : int = w*h, b : Boolean = true;
    		plasma = new Vector.( l, false );

			while(  --l > - 1 )
			{
  				x = l % w;
				y = (l - x) / w;
				var color : Number;

				if ( b )
					color = (128+(128*Math.sin(x/128))+128
					+(128*Math.sin(y/128)))/2;
				else
					color = (128+(128*Math.sin(x/16))+128
					+(128*Math.sin(y/8))+128
					+(128*Math.sin((x+y)/16))+128
					+(128*Math.sin(Math.sqrt(x*x+y*y)/8)))/4;

        		plasma[l] = color;
        		b = !b;
    		}

			// init screen
			for( x = 0; x < w; x++ )
			{
				for( y = 0; y < h; y++ )
				{
					var pos : Number = (x+(y*w))*4;
					ba[pos] = 255;
					ba[pos+1] = 0;
					ba[pos+2] = 0;
					ba[pos+3] = 0;
				}
			}

			addEventListener( Event.ENTER_FRAME, enterFrame );
		}

		protected function enterFrame( e : Event ) : void
		{
			bd.lock();
			var t : int = ++shifter, pos : int = w*h, palID : int, ID : int;
			while ( --pos > - 1 )
			{
					palID = int((plasma[pos] + t) % 255);
					// to process ARGB channels, same as pos *= 4;
					ID = int(pos << 2);
					ba[ID]	= A[palID];
					ba[ID+1]= R[palID];
					ba[ID+2]= G[palID];
        	}
			ba.position = 0;
			bd.setPixels( rect, ba );
			bd.applyFilter( bd, bd.rect, p, blur );
			bd.unlock();
		}
	}
}

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>

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.

Je code depuis deux semaines une nouvelle librairie dont l’objectif final sera de faciliter la programmation des jeux en Flash.
Nom de code : pixLib

Mon premier challenge fut de réaliser un tiles engine abstrait qui puisse être injecté dans le code principal de n’importe quel view d’un jeu afin obtenir un affichage 2D, isométrique, pseudo 3d …
Ce week-end, j’ai pris une journée pour développer quelques exemples basiques illustrant l’utilisation du premier set de classes disponible.

Une classe abstraite VisualGrid sert de fondation pour les différentes représentations graphiques. Elle permet grâce à la magie du polymorphisme d’interchanger à tout moment l’univers visuel d’un jeu et ce sans changer une ligne de code de celui-ci.

// exemple avec view 2d

import com.bourre.tests.tetris.Tetris;
import com.bourre.visual.Visual2DGrid;

var game:Tetris = new Tetris();
game.main(new Visual2DGrid(this, 1, 12, 21, 32, 32, 100, 10));

// exemple avec view iso

import com.bourre.tests.tetris.Tetris;
import com.bourre.visual.VisualIsoGrid;

var game:Tetris = new Tetris();
game.main(new VisualIsoGrid(this, 1, 12, 21, 28.5, 14.25, 625, 120));

Pour les ébauches en image, ça se passe ici, ici, ici et ici.
On sera indulgent sur les graphismes, ceci n’étant pas mon domaine de prédilection. ^^

Prochaine étape, créer un moteur d’animations. En effet, le tiles engine est pour l’instant statique.

A suivre donc !

ps : Merci à rosyflower pour le sweety logo !

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.