Since my previous article (FR), I have kept on working on the dependencies injector of Spiral, wich I just published in a standalone version.

Here is an overview of SpiralDi functionnalities, and some examples on the use.

Table des matières

Overview

SpiralDi comes with a lot of new features, some of them inspired by the excellent Java framework : Spring. It is now possible to :

• Use factories to set the parameters values (useful for configuration)
• Use an inheritance system to make configuration file more clear
• Use factories for the construction of the services
• Directly inject the container in ContainerAware services

But, maybe, it doesn’t mean anything for you ? I will explain the details further later.

Principles

If you don’t know much about the inversion of control, I advise you to read my introduction on the dependencies injection (FR).

The use of a lightweight container is done in two steps :

• The description of the schema of all the services that will be used later
• The call (so, the construction) of these services via the container

The SpiralDi library let you describe the Schema in different ways. The sexiest is probably the XML description file, but it is also possible to define this Schema using the PHP language if you think it’s more convenient. The following examples are in XML. Here is a quite simple definition file, that describe two services :

Once this file is written, you have to transform it in a SpiralDi understandable format : the Schema.

You can now exploit the built Schema. The Schema is first used to resolve objects. We will see later that it has much more aims. Now, pass this Schema to the Container :

This looks sexy, isn’t it ? The container has done everything ! Resolution of the object’s dependencies and injection of these dependencies when needed.

Services scope

All services constructed by SpiralDi have a controlled life time.
In the default behavior, the container will return the same instance of the object, each time the service is needed. This is the singleton scope.
All services are by default configured to have the singleton scope.

You can also use the prototype scope to make the container create a new instance each time the service is needed.

To change the scope of the service, you can use the property

in the XML file.

Advanced use

Now, you know how to describe « basic»  services and their dependencies. Let’s see now, more complex features.

Using references and MethodFactory

Sometimes, you will need to inject parameters in a dynamic manner. Imagine that you don’t know the value of a parameter that you want to inject because it is stored in a configuration object for example.

So, we want the container to construct our services using information from a Config object. The container is able to generate automatically the following code for us :

For this, we have to use the system of references :

It is also possible to specify the method that will be used to get arguments. For example

will produce something like this :

The corresponding XML code will be :

Inheriting and overloading services

Quite often, some services are similar. It is possible to use the inheritance system to make the services description lighter.
This is not an actual inheritance between classes, but only the inheritance principle. Thus, you can extend a service description, which make the description file more readable and easier to understand.

Container Aware

In some cases, services have to know the existence of the container, and need to access to it. It is easy to inject the container in a service by using the « container»  type or the facility « containerAware»  :

From the class’ point of view, you only have to implement the SpiralDi_ContainerAware interface. In this way, during the construction of the service, the setDiContainer method of your class will be automatically called.

As well, in this case, there is no need to explicitly name your service as « ContainerAware»  in the description file, the container will automatically detect it

Factories

SpiralDi also provides a convenient way to use Factories from the DI. This helps generating behaviors like :

The corresponding XML code is :

This should be nice if you want to reuse your old Singleton implementations, among other things…

Download it !

Convinced ? To get the latest version of SpiralDi, you have many solutions :

Via the mercurial repository

Via the archives

The code is available in the following formats : zip, gz ou bz2

You can also directly check the repository.

That’s all ! You can now have fun using it ! For functionnality requests, bug report, etc. Please !

Interesting readings

If you want to know more about dependencies injection, here are some interesting readings on the subject :

• Martin Fowler’s article on dependencies injection
• Fabien potencier’s suite of articles (1,2,3,4,5)
• Another one from Padraic Brady (1,2)
• Fabien Potencier has also published a di container that feet in a tweet. to see, just for fun

Going further ?

SpiralDi is of course not the only PHP lightweight container. Recently, a lot of container are flowering on the web. Frameworks like Symfony and Flow3¹ are giving a good place to DI. So much the better !

• Symfony’s services container
• Yadim
• Flow3 Objects
• Sphicy
• Phemto
• Seasar
• Garden
• Xyster
• Lion

1. It is new, beautiful, written for PHP 5.3, using AOP, Domain Model persistence… and of course dependencies injection ! Keep an eye on it : Flow3

Suite à mon précédent article, j’ai continué à travailler sur l’injecteur de dépendances de Spiral, que je viens de publier dans une version standalone.

Voici un tour d’horizon des fonctionnalités apportées par SpiralDi, ainsi que quelques exemples d’utilisation.

Table des matières

Tour d’horizon

SpiralDi arrive avec son lot de nouveautés, pour certaines inspirées de l’excellent framework Java Spring. Il est désormais possible, en vrac, de:

• Utiliser des factories pour renseigner les valeurs des parametres (pratique pour la configuration)
• Utiliser un système d’héritage, pour alléger les fichiers de configuration
• Utiliser des Factories pour résoudre les services
• Injecter directement le conteneur à certains services, dits ContainerAware

Mais peut être que ça ne vous parles pas trop, nous y reviendrons tout à l’heure.

Principes

Si vous n’êtes pas à l’aise avec le principe d’inversion de contrôle, je vous conseille d’aller lire mon introduction sur l’injection de dépendances.

L’utilisation d’un conteneur léger se fait toujours en deux étapes:

• La description et le renseignement du schéma de services qui pourront être utilisés par la suite
• la demande de résolution de ces derniers, via le conteneur

SpiralDi fournit plusieurs manières de décrire le Schema. La plus appropriée est surement l’XML, mais il est également possible de passer via du PHP si cela vous semble plus pratique. Nous prendrons ici l’exemple du XML. Voici un fichier de description assez simple, qui décrit deux services:

Une fois le fichier écrit, il faut le transformer dans un format compréhensible par SpiralDi: le Schema.

Nous pouvons désormais exploiter notre Schema. La première utilité d’un Schéma est d’être utilisé pour résoudre nos objets. Nous verrons un peu plus tard qu’il peut avoir d’autres utilités. Passons donc le Schema au Conteneur:

Plutôt sympa non? Le conteneur s’est occupé de tout: résolution des dépendances de l’objet, et injection de ces dernières quand nécessaire.

Portée des services (Scopes)

Les services construits via SpiralDi ont une durée de vie contrôlée.
Par défaut, plusieurs demandes au conteneur pour un même service retournerons la même instance de l’objet, il s’agit de la portée de type singleton.
Le conteneur est configuré par défaut pour que les services qu’ils crée aient une portée de type singleton.

Il est possible d’utiliser la portée prototype pour qu’un nouvel objet soit créé à chaque appel du service, en utilisant la propriété

dans le fichier XML.

Utilisation « avancée» 

Vous savez désormais comment décrire « basiquement»  vos services et leurs dépendances. Voyons maintenant quelques concepts un peu plus poussés.

Utilisation des Références et des MethodFactory

Il peut arriver que l’on ai besoin d’injecter des paramètres de manière dynamique. Imaginez que vous ne connaissiez pas la valeur des paramètres à injecter, ceux-ci étant contenus dans un objet de configuration par exemple.

Nous souhaitons donc que le conteneur construise nos objets en utilisant des informations contenues dans la configuration. Le conteneur est donc capable de s’occuper de générer le code suivant à notre place:

Pour cela, il faut utiliser le système de réferences:

Il est également possible de spécifier la méthode à utiliser pour résoudre les arguments,

par exemple, pour arriver à quelque chose de ce genre:

Le code XML est alors le suivant:

Héritage et surcharge de services

Assez souvent, certains services à injecter se ressemblent. Il est possible d’utiliser un système d’héritage pour rendre la description des services moins rébarbative. Il ne s’agit pas d’un héritage « concret»  dans nos classes, mais du principe de l’héritage. Ainsi, une description peut en étendre une autre, facilitant à la fois son écriture et sa compréhension.

Container Aware

Dans certains cas, il peut être utile qu’un service soit conscient de l’existence du conteneur, et qu’il puisse y accéder. Il est facile d’injecter le conteneur dans un service, en utilisant le type « container» , ou la facilité « containerAware» :

Du coté de votre classe, si celle-ci doit récupérer le conteneur, elle à simplement à implémenter l’interface SpiralDi_ContainerAware. Lors de sa construction, la méthode setDiContainer sera directement appelée.

A noter que dans ce cas, il n’est pas nécessaire de définir votre service comme étant « ContainerAware» , le conteneur étant capable de le découvrir tout seul.

Factories

Il est également possible d’utiliser des Factory depuis le DI, pour générer un comportement comme celui ci

Le code XML correspondant est le suivant:

Cela peut s’avérer pratique pour récupérer vos anciennes implémentations du pattern Singleton entres autres…

Téléchargez le !

Convaincu ? Pour récupérer la dernière version de SpiralDi, vous avez le choix entre plusieurs solutions:

Via le dépôt mercurial

Via les archives

Le code est disponible en zip, gz ou bz2

Vous pouvez aussi aller jeter directement un oeil au dépot.
Et voila! Vous avez de quoi vous amuser ! Pour toute demande de fonctionnalité, rapport de bug etc, n’hésitez surtout pas!

Et ailleurs ?

SpiralDi n’est bien évidemment pas le seul Conteneur Léger écrit en PHP. Depuis peu, ces derniers commencent d’ailleurs à fleurir sur la toile. Les frameworks Symfony et Flow3¹ leur font d’ailleurs la part belle, et c’est tant mieux! Quelques alternatives possibles au conteneur de Spiral donc:

• Le service container de symfony
• Yadim
• Flow3 Objects
• Sphicy

Lectures intéressantes

Si vous souhaitez aller plus loin, voici quelques lectures intéressantes sur le sujet de l’injection de dépendances:

• L’article de Martin Fowler sur l’injection de dépendances
• La série d’articles de Fabien potencier (1,2,3,4,5)
• Celle de Padraic Brady (1,2)
• Les conteneurs légers du futur, par Sami Jabber

1. Il est tout nouveau, tout beau, en PHP 5.3, utilise l’AOP, la persistance Domain Model … et l’injection de dépendances! A suivre de très près: Flow3

Avant tout, il faut bien comprendre que sans contexte il n’existe pas de manière plus censée qu’une autre pour construire une application. Il existe par contre un ensemble de bonnes pratiques qu’il est bon de connaitre et d’appliquer, dans la plus large mesure possible. Ces pratiques sont souvent mal connues, et nombre d’entre elles sont appliquées à la va vite.

Nous allons tenter d’expliquer ici pourquoi et comment l’implémentation la plus rependue du singleton favorise la création de dépendances, et comment nous pouvons y remédier, grâce à l’injection de dépendances.

Le singleton

Le singleton, à l'origine de dépendances

Le Singleton est un patron de conception (souvent le premier patron de conception qui nous est présenté) qui doit être appliqué avec précaution. Son utilisation est souvent mal comprise et celui ci peut être considéré à tort comme une solution « miracle»  pour accéder facilement à un objet, comme on le ferait d’une variable globale. On dit d’ailleurs aussi qu’il s’agit de l’antipattern singleton, à raison. Pourquoi ?

Très rapidement, un singleton est une classe dont il existe un nombre défini d’instances. Typiquement, le singleton est utilisé afin de réduire le nombre possible d’instances d’une classe à une seule. Cela peut être très utile, et est utilisé dans de nombreux cas à bon escient (je pense par exemple à l’accès à une base de données).

Un des défauts majeur de ce motif, est l’implémentation la plus souvent présentée, qui va de paire avec l’usage de méthodes statiques pour récupérer une instance de la classe. Pour mieux comprendre, voici l’implémentation type, en PHP (le motif est sensiblement le même dans de nombreux langages):

Ici, pour récupérer l’instance de la classe, il est nécessaire de faire appel à la méthode statique getInstance de la classe DbConnection_Mysql.

Il est alors nécessaire, dans la classe utilisatrice du singleton (imaginons qu’il s’agisse d’une classe User), de hardcoder le nom de la classe DbConnection_Mysql, la classe A devenant alors dépendante de cette implémentation particulière du singleton.

Avec cette implémentation, il est impossible de changer la classe en charge de la connexion à la base de données sans modifier le code. Imaginons que nous souhaitons utiliser la classe DbConnection_Oracle par exemple, nous sommes bloqués. Il s’agit d’une problème de conception, et peut faire perdre un temps important lors du développement.

Inversion de contrôle / Injection de dépendances

Comme nous venons de le voir, le singleton, ou plutôt, cette implémentation du singleton, introduit et favorise les dépendances entre nos classes.

Une des solutions possible est d’inverser le flux de contrôle de notre application: au lieu que ce soit la classe User qui appelle directement DbConnection_Mysql, celui ci peut être crée en amont, pour être ensuite injecté dans la classe qui souhaite l’utiliser. De cette manière, Ce principe à un nom, il s’agit de l’injection de dépendances.

Théorie

Alice a besoin d’une Glace pour la manger().
Alice aime les GlaceALaFraise… Si on donne de l’argent à Alice elle achète systématiquement une GlaceALaFraise. Alice est bloquée au seul parfum « fraise des bois»  aussi savoureux soit-il.

Pour lui faire découvrir de nouvelles saveurs sa Maman décide de ne plus laisser Alice choisir sa Glace elle-même, mais se charge de choisir pour elle une GlaceAuPaté.

Quels que soit les goûts d’Alice, une GlaceAuPaté reste une Glace, et donc Alice est tout à fait à même de la manger()¹.

Le concept exposé ici est connu comme le principe d’Holywood: « Ne vous appelez pas vous même, nous vous appellerons» .

Ce qu’il faut retenir, c’est qu’Alice peut, si elle le souhaite, manger() tout type de Glace, même si au départ Alice n’à besoin de manger() q’une GlaceALaFraise. Nous favorisons ici la réutilisations du code: nous pouvons réutiliser Alice facilement et substituer sa Glace par une autre facilement.

Application à notre exemple

Reprenons l’exemple des utilisateurs et de l’utilisation de la DbConnection pour y appliquer ce principe d’inversion de contrôle. Notre code ressemblerait alors à quelque chose dans cet esprit:

Avec les deux interfaces/implémentations suivantes pour DbConnection et User:

Ici, il subsiste des dépendances dans le code. Il s’agit de dépendances vis à vis de contrats (interfaces) et non d’implémentations données (classes), puisque j’ai choisi d’utiliser le paradigme de programmation par contrats.

Nous avons parlé de singleton et de création de dépendances, mais l’injection de dépendances est applicable à tout type de classes, et devrait d’ailleurs être utilisé dans la plupart des projet d’importante envergure.

Utilisation d’un conteneur

schéma des dépendances entre nos classes

Pour aller un peu plus loin, il peut être utile et efficace de déléguer la tâche de création des objets à un conteneur. Il s’agit d’une classe, en charge de la création de tous les objets, ce dernier pouvant résoudre les dépendances nécessaires à la création de l’objet souhaité.

Nous avons donc le schéma de dépendances décrit à gauche. Une fois ces informations fournies au conteneur (via un fichier de configuration), nous pouvons facilement récupérer l’object User_Default en le demandant à notre conteneur:

. Ce dernier se charge alors de créer l’ensemble des dépendances de cet objet (un objet de la classe DbConnection_Mysql ici). Plutôt sympa, non ?

Pour faire en sorte que la classe d’accès aux données soit un singleton, c’est le schéma qu’il faut alors modifier (via le fichier de configuration ici.)

Ici, j’ai essentiellement parlé de dépendances entre classes. Cependant, de la même manière, il est possible de contrôler tous les arguments passés à nos objets, qu’il s’agisse de tableaux, de chaines de caractère ou autres.

Moi aussi j’en veux ! Spiral Di Container

Pour mon usage personnel, j’ai développé un injecteur de dépendances flexible, permettant d’appliquer ce modèle à mes futurs développements. Il existe déjà des projets similaires, mais ces derniers font un usage trop abusif – à mon gout – du mécanisme de réflexion, perdant alors grandement en performance.

Voyons comment nous pouvons utiliser le conteneur dans notre cas. Cela revient à créer le schéma de dépendances. Cela est possible pour le moment par 2 biais: via XML ou directement via php.

Directement via php

Via un fichier XML

Il est à noter que le fichier XML à été directement généré via le Dumper Xml, en utilisant le schema.

Si vous êtes interessé pour regarder plus en détail le fonctionnement de ce conteneur, les sources sont d’ores et déjà disponibles via le framework de travail spiral, disponible via son dépot mercurial.

L’injecteur de dépendances est présent dans la partie /core/Di de l’architecture. Une version standalone devrait bientôt voir le jour.

Si cet article vous à plu, je publierais prochainement une série d’article expliquant en détail comment utiliser un conteneur de dépendances, en m’appuyant sur des exemples concrets que j’ai pu rencontrer.

Ah, et j’oubliais, un grand merci aux relecteurs pour votre aide précieuse ! (Fred, David, Florent, Joel, Nico …)

1. Merci Frédéric pour ton super exemple !