KiloOctet Blog

PureMVC - Le KoMediator, un Mediator un petit peu plus souple (selon moi)

Salut à tous,

J'explore actuellement les frameworks proposant une implémentation du principe MVC+C (dit aussi FrontController) .

J'ai découvert PureMVC qui est pas mal dans son genre. ( Et je ne suis pas le seul à le dire

Si vous venez, comme moi, de PixLib / LowRA ou Cairngorm, un peu de traduction s'impose ! Dans PureMVC, les ViewHelper sont des Mediator, les Events des Notifications et les EventBroadcaster des Observer.

C'est le Mediator qui m'intéresse tout particulièrement ici.

Dans PureMVC, chaque Mediator posséde une constante statique publique NAME de type String. Elle détermine son identifiant unique. Mais comme il s'agit d'une constante on doit la définir dans le code, pas de possibilité de la définir au runtime. Afin de référencer les Mediator, la classe View centralise leur accès en appelant sur chaque Mediator référencé, la méthode getMediatorName(). Du coup, il faut dans chaque classe étendant Mediator, copier/coller le code de la méthode getMediatorName(), pour quelle accéde bien à la constante de notre classe et non à celle de la super classe.

 
override public function getMediatorName() : String
{
return NAME;
}
 

Un peu lourd, je trouve et surtout pas très heureux dans le genre.

Lors de l'enregistrement d'un Mediator dans la classe View, cette dernière va aussi demander une liste des Notifications auxquels ce Mediator devra être abonner. Pour cela il passe par la méthode listImplementations qui renvoie un tableau de type de Notification (String). Le callback pour chaque Notification est le même une méthode handleNotifications( notification : INotification). Du coup, il faut faire un switch dans chaque Mediator pour adapter la logique selon le type de Notification reçue. Brrrrr...

Je propose donc une classe KoMediator avec deux solutions qui me semblent un peu plus élégantes :

1- Le nom du Mediator

Pour cela j'utilise une propriété d'instance privée, transmise au constructeur. Ce qui permet d'utiliser une seconde classe qui va simplement lister les noms uniques de nos Mediator en constant publique de classe et notre classe héritant du KoMediator, passera la référence à cette variable :

 
class ExampleMediator extends KoMediator
{
public function ExampleMediator( document : Object = null )
{
super( document, MediatorList.EXAMPLE )
}
} 
 
class MediatorList
{
public static const EXAMPLE : String = "example";
}
 

Ainsi la signature de notre Mediator est la même que celui du Mediator d'origine de PureMVC

2- Gérer les notifications avec une méthode pour chaque et sans switch

Pour cela, j'ai "extrait" la classe HashMap de LowRA et me suis contenté de la rendre indépendante du reste du framework. Le code complet de cette classe est donc bien de Francis Bourre. Je me sert donc d'une instance de Map pour garder la liste de mes notifications en clefs, la valeurs correspondantes étant la méthode qui va recevoir la Notification.

 
class ExampleMediator extends KoMediator {
public function ExampleMediator( document : Object = null )
{
super( document, MediatorList.EXAMPLE )
_mNotificationInterest.put( NotificationList.MODEL_UPDATED, onModelUpdate )
}
private function onModelUpdate( notification : INotification ) : void
{
}
}
 

Ainsi on a une implémentation bien plus simple et proche du EventBroadcasting classique.

Enfin je trouve.

Pour ma part.

Et de mon humble avis...

Et vous ?