Wiki - 1 output

^Construire des logiciels modulaires et évolutifs

L’AOP permet de d’appeler des fonctions avant ou après des fonctions existantes du logiciel, qui n’ont pas été spécifiquement conçues pour permettre le déclenchement d’événements.

Les événéments permettent l’appel de fonctions à des points du programme prévus pour, dans un contexte donné. Ils sont en général prévus dans des traitements génériques, utilisés par de nombreuses classes d’objets différentes, mais où l’on veut pouvoir brancher des fonctions de modules qui ne soient appelés que pour les classes concernées.

Par exemple pour déclencher un traitement après l’envoi d’un mail, vous vous brancherez en utilisant l’AOP après la méthode Sender::send(). Cette méthode est spécifique aux mails, chaque appel à votre greffon AOP sera donc opportun.

Si vous souhaitez déclencher un traitement après la sauvegarde d’un mail avec le lien de données courant, c’est sur la fonction générique Dao::write() que vous allez devoir vous brancher. Si vous utilisez l’AOP, votre greffon sera appelé pour chaque sauvegarde de mail, mais également lors de la sauvegarde de n’importe quel objet. Vous allez donc devoir tester en début de greffon l’objet sauvegardé pour n’agir que s’il s’agit d’un mail, et ne rien faire si l’objet est d’une autre classe. L’inconvénient est que si vous avez un gros logiciel de gestion, de nombreux modules vont potentiellement vouloir rajouter des traitement spécifiques à telle ou telle classe au moment de l’enregistrement d’objets de cette classe : de nombreux greffons seront appelés, la plupart juste pour tester la classe de l’objet et finalement ne rien faire, ce qui va allourdir le traitement d’enregistrement au fur et à mesure que des ajouts spécifiques sont prévus.

C’est pourquoi une boucle de traitement d’événements est prévue lors de l’enregistrement des objets, pour n’appeler des traitements que s’il en est prévu, et que ceux de la classe de l’objet enregistré. Plutôt que faire un branchement AOP, on préférera donc déclarer la fonction appelée lors de l’événement dans l’objet, ou un trait additionnel :

use ITRocks\Framework\Traits\Has_Name;
 
/**
 * @after_write yourMethodAfterTheObjectIsWritten
 */
class Your_Class
{
	use Has_Name;
 
	public function yourMethodAfterTheObjectIsWritten()
	{
		echo "Your object $this has been written" . BR;
	}
 
}

L’utilisation d’événements de préférence à l’AOP permet donc :

- une déclaration simplifiée, lorsque vous souhaitez capturer des événements touchant aux classes que vous développez
- d’éviter d’alourdir l’appel à des traitements communs sur lesquels les branchements modulaires de traitements ajoutés sont fréquents.

Pour aller plus loin

- Utiliser les événements du framework
- Créer un événement sur un traitement de vos modules
- Créer un événement sur un traitement d’un module tiers