L’article est également disponible en PDF si vous souhaitez.

L’article !

Un injecteur de dépendances ? Peut être cela ne vous parle il pas vraiment. Tant mieux, l’objectif de cet article est d’éclaircir ces termes, et de présenter une implémentation que j’ai eu l’occasion de mettre en place, en essayant de m’appuyer sur de bonnes pratiques logicielles.

Cet article est basé sur mon expérience personnelle, ainsi que sur des recherches effectuées lors de la réalisation d’un composant logiciel. L’objectif n’est aucunement d’imposer ma vision des choses, mais bel et bien de partager les interrogations, réflexion et découvertes que nous avons eu alors.

Nous parlerons ici de l’injecteur de dépendances de Spiral, un framework maison réalisé avec quelques amis, et dont l’objectif principal est de découvrir les rouages des frameworks, ainsi que de nous initier aux bonnes pratiques logicielles.

Alors que nous travaillions sur ce projet, notre principal but était de réellement comprendre, dans le détail, comment un injecteur de dépendances pouvait fonctionner. Ré-inventer la roue, pour mieux comprendre comment une roue fonctionne, en quelque sorte.

Aussi, l’objectif de ce document n’est pas de fournir une documentation sur l’utilisation du composant, mais bien d’expliquer comment nous l’avons réalisé.

L’injecteur de dépendances est disponible dans une version intégrée à Spiral ou dans une version standalone. Vous pouvez trouver le code sur le dépôt mercurial du projet.

A l’heure ou j’écris ces lignes, l’injecteur de dépendances de spiral n’est pas encore terminé (sept 09), mais est dans un état avancé, et devrait être disponible en novembre 2009.

L’ensemble des exemples de ce document sont en PHP, mais les concepts discutés ici peuvent être (et sont!) implémentés dans d’autres langages.

Donc, parlons un peu d’injection de dépendances !

Comment gérons-nous nos objets ?

Avant toute chose, il est indispensable de bien comprendre ce qu’est l’inversion de contrôle.

Lorsque nous réalisons des logiciels en utilisant le paradigme orienté objet, nous travaillons avec des classes, et la majeure partie du temps, nous faisons interagir ces classes entre elles. En pratique, certaines classes sont dépendantes d’autres classes.

Pour mettre un exemple derrière ces concepts, tout au long de ce document, nous allons nous mettre dans la peau d’Alice, une jeune fille qui adore manger des glaces, spécialement celles à la fraise !

Certains disent même qu’Alice est dépendante de la glace à la fraise.

Il est clair, au regard de cette implémentation, qu’à chaque fois qu’Alice mange une glace, il s’agit d’une glace à la fraise. Génial, mais un jour, la mère d’Alice souhaite lui faire découvrir d’autres parfums…

En réalité, avec cette implémentation, il est impossible de changer la glace qu’Alice va manger.

Inversion de Contrôle (IoC)

Principe

Il apparait donc nécessaire de supprimer les dépendances entre nos deux classes, pour permettre à Alice de gouter de nouveaux parfums.

Comment ? C’est assez simple, regardez donc le code:

Quand Alice mange une glace (via la méthodemangerGlace), nous devons lui passer la glace, ce n’est plus elle qui choisit, nous le faisons à sa place.

Ce principe est connu comme étant le principe d’Hollywood: « Ne nous appelez pas, nous vous appellerons» . En d’autres termes, n’utilisez pas l’opérateurnewdans vos classes, mais préférez passer (ou qu’on vous passe) les objets par référence.

Alice peut faire d’autres choses avec sa glace, la laisser tomber par terre par exemple (oups!), grâce à la méthodelacherGlace(). Nous pouvons alors choisir de passer la glace à cette méthode également, ou choisir de la donner directement à Alice, la laissant s’occuper du reste, et évitant de lui passer une glace pour chaque action qui en nécessite une.

Il est bien plus facile maintenant de choisir la glace à donner a Alice, et ainsi de contrôler les dépendances d’Alice vis à vis de la glace.

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.

Et c’est tout pour le principe d’inversion de contrôle (pas les glaces à la fraise, contrôler les dépendances)! Il s’agit simplement du fait d’inverser le flux de contrôle de vos application, en déléguant à un plus haut niveau la création des objets.

Injection de dépendances

Maintenant que le concept d’inversion de contrôle est clair, expliquons ce qu’est l’injection de dépendances. Les deux concepts sont assez proches, et souvent utilisés de pair, mais il est important de bien saisir la frontière entre les deux.

Dans la méthodemangerGlace, nous considérons que la glace en question est déjà donnée à Alice. C’est un comportement vraiment utile: Nous n’avons plus à nous occuper de la manière dont la glace est arrivée là, nous l’avons déjà (dans une propriété privée par exemple).

Dans la section précédente, Alice était dépendante de sa glace. En inversant le flux de contrôle, le comportement d’Alice vis à vis des glaces est plus facilement contrôlable, et testable (utiliser des mocks, ou bouchons de tests est aussi facile que de régler une propriété, nous parlerons de tests plus tard).

Notre travail (celui de la mère d’Alice), est de créer les objets et de les passer à Alice. Les injecter est le bon mot. En utilisant des mutateurs, ou en utilisant le constructeur, injectant les objets nécessaires.

Allons-y:

L’inversion de contrôle est donc le fait d’exposer des méthodes publiques (ou des constructeurs) pour régler certaines propriétés, et l’injection de dépendances est le fait de, justement, injecter ces dépendances, utiliser ces méthodes et constructeurs.

Un Conteneur ?

L’exemple utilisé jusqu’ici est volontairement simple, et il à été choisi afin d’expliquer les concepts le plus clairement possible: Nous avons uniquement deux classes, et une dépendance.

En pratique, vous serez surement d’accord pour dire qu’un projet est rarement aussi simple. Aussi, dans les projets importants, la gestion du cycle de vie des objets et de l’injection de leurs propriété peut rapidement devenir un vrai casse tête.

L’idéal est alors d’automatiser le processus de création, d’injection et de gestion de ces cycles de vie. Le conteneur fait exactement ça.

Pourquoi « conteneur»  ? Parce que la création automatique et l’injection est effectuée grâce à un objet, qui se charge de contenir toutes les informations sur les dépendances. Une fois les objets crées, le conteneur garde une référence vers ces derniers au cas ou nous en aurions encore besoin (voir la définition de portée d’un service – les « scopes» - plus loin)

Le conteneur va donc se charger d’injecter les objets pour nous, en quelque sorte, il fait le travail de la Mère d’Alice à sa place.

Nous souhaitons donc que lorsque nous appellerons Alice, via le conteneur, elle nous soit retourné avec une glace prête à être mangée !

Ici, le conteneur à injecté la bonne glace à Alice (peu importe laquelle d’ailleurs, nous souhaitons juste avoir une glace)

Si la glace elle même avait été dépendante d’autres objets (disons, des noix de coco par exemple), c’est le rôle du conteneur que de résoudre l’ensemble des dépendances, dans le bon ordre, simplifiant au maximum la tâche de gestion des dépendances entre les objets et les classes, laissant la tâche simple pour le développeur.

Concepts logiciels

Maintenant que les concepts d’inversion de contrôle et d’injection de dépendances sont clairs (enfin, j’espère!), nous pouvons commencer à parler de comment nous avons réalisé cette bibliothèque.

Les concepts discutés ici sont des concepts assez simples, dont le principal objectif est de fournir une structure solide aux composants. Chaque composant à ainsi un rôle et un emplacement précis au sein de notre architecture.

Le Schéma

Dans le schéma, et dans l’injecteur de dépendances en général, un « service»  est un objet qui est géré par le conteneur.

Le schéma représente les liens entre les différents services. Il décrit les dépendances de nos objets.

Si vous connaissez le patron de conception de fabrique abstraite, vous pouvez vous représenter le schéma comme une configuration alors que le conteneur serait la fabrique elle même (ou quelque chose d’approchant).

Le schéma contient toutes les informations sur les méthodes qui doivent êtres appelées pour injecter les objets, le type des arguments qui doivent être passés, et tout autre type d’information potentiellement utile au moment de l’injection.

Pour en revenir à notre exemple, le schéma contiendrait des informations sur le type de glace qui doit être passée à Alice (Une glace à la fraise bien sur!), et sur la manière de donner cette glace à Alice (via la méthodesetGlace())

Jusqu’à maintenant, nous avons parlé de dépendances simples, mais le schéma peut aussi gérer d’autres types de services, méthodes et arguments. Tout est décrit dans les sections suivantes:Services,MethodsetAttibutes.

Services

Un service représente un objet. Dans notre exemple, la Glace et Alice sont des services.

Un service se compose d’:

• un nom
• un ensemble de méthodes
• une manière de se construire
• une portée (scope)

La portée d’un service définit comment la durée de vie des services doit être gérée par le conteneur: Est-ce que le service doit rester dans le conteneur pendant toute la durée du script (singleton), ou doit il être systématiquement supprimé après avoir été construit (prototype)?

L’instance de l’objet courant peut être la même pour l’ensemble des services si la portée du service est définie comme étant un singleton, ou être à chaque fois différente si la portée est définie comme prototype.

D’autres types de portées peuvent êtres imaginées comme une portée de « session» , qui retournerait la même instance durant une session unique, ou une sorte de portée « immortelle» , qui retournerait toujours le même objet, en faisant persister cet objet à travers différentes sessions.

L’injecteur de dépendances est fourni avec les types de service suivants:

Défaut : Un service « simple» , composé de méthodes, et qui peut être construit comment un simple objet.

Alias : Un alias vers un autre service. Seul le nom est différent. Ce type de service permet de gérer facilement les dépendances dans le temps. « Pour le moment, il s’agit d’un alias, mais peut être qu’un jour nous aurons besoin d’un autre type de service» .

Héritage de services : Plutôt que de se répéter maintes et maintes fois lors de la description de services qui se ressemblent, il est possible d’utiliser l’héritage. Cela ressemble grandement à l’héritage de classes: les méthodes que vous redéfinissez ou ajoutez dans les services enfants écraseront ceux des parents.

Méthodes

Chaque service contient des méthodes.

Une méthode permet d’injecter certains paramètres dans nos services, ou de définir certaines ressources qui doivent être appelées au moment de la construction des services. Dans le cas d’Alice,setGlace()est une méthode.

Une méthode est composée d’:

• un nom,
• optionellement, un nom de classe
• une liste d’arguments
• une information disant si la méthode est statique ou non

Voici les différents types de méthodes actuellement implémentées:

Défaut : Une simple méthode, avec des arguments. Peut être une méthode statique

Attributs : Utilisé pour régler directement les propriétés en utilisant les attributs publics de l’objet ($service->attribut = $valeur`). Ce type de méthode peut contenir uniquement un argument. Il peut paraître étrange de gérer les attributs comme des méthodes. En réalité, il est important de comprendre la différence entre une méthode et un argument. Alors qu’un argument représente une valeur, une méthode représente une manière d’utiliser ces arguments. Dès lors, il parait plus logique de gérer les attributs comme des méthodes que comme des arguments.

Rappels (callbacks) : Avant ou après la création de vos services, il est possible d’appeler des méthodes spécifiques, appelées méthodes de rappel.

Arguments

Les méthodes contiennent donc des arguments, et il existe plusieurs types d’arguments également.
Les arguments sont le bout de la chaine services / méthodes / arguments.

Défaut : Types PHP natifs (int, string, float etc)

Conteneur : Il est possible d’injecter directement le conteneur. Ce type d’argument n’est utilisé que par les services qui nécessitent d’utiliser le conteneur. Ils sont appelées services « ContainerAware» .

Service courant : Il est possible d’injecter le service en cours, et de l’utiliser comme argument. En pratique, ceci est uniquement utile pour les méthodes de rappel (callback)

Argument vide : Il s’agit d’un type d’argument qui na pas de valeur. L’argument « conteneur»  et « service courant»  étendent ce type. Attention, l’argument vide est différent de null.

Référence à un service : C’est un des types d’argument le plus utilisé, il représente un autre service.

Argument résolu grâce aux services : Parfois, il est utile d’utiliser un service pour récupérer un argument, je pense à la configuration entres autres. Ce type d’argument utilise donc une méthode spécifique d’un autre service pour être résolu.

Stratégies de construction

Maintenant que nous avons un schéma qui représente les relations entre nos services, nous allons nous occuper de la construction de ces services.

Nous avons choisi de séparer complètement les logiques de construction et de définition, pour permettre de favoriser un maximum d’usages possibles pour l’un et l’autre des composants.

Chaque type, dans le schéma, peut être lié à un type de stratégie pour se construire. Il y à donc plusieurs stratégies de construction pour les services, les méthodes et les arguments.

L’intérêt d’utiliser des stratégies de construction est de permettre à chacun de nos types, dans le schéma, de se construire eux même, en utilisant leur méthodebuild(), qui va elle déléguer la tache de construction aux stratégies.

En interne, il est possible d’utiliser des stratégies de construction différentes, et d’en changer à tout moment. Ce comportement suit, en fait, le patron de conception stratégie.

Builders / Monteurs

Puisque nous parlons de patrons de conception (design patterns), parlons du motif « Monteur» .

Vous serez sans doute d’accord avec moi pour dire qu’écrire un schéma entièrement à la main, en utilisant les classes dont nous avons parlé un peu plus haut peut s’avérer rapidement assez pénible. En tout cas, pour l’avoir expérimenté lors de l’écriture des tests, je peux dire qu’il ne s’agit pas d’un gain de temps, loin de là.

Une solution pratique consiste à utiliser le motif Monteur. L’idée est d’écrire le schéma sous une forme sympathique et facile à écrire pour nous, développeurs, et d’utiliser une classe intermédiaire pour transformer notre représentation du schéma dans la représentation compréhensible par notre composant.

Cette classe intermédiaire monte donc notre schéma, en déchiffrant une autre structure.

Le premier type de monteur qui me vient à l’esprit (le plus pratique, en fait), est le monteur XML. Il est capable de lire un schéma, décrit au format XML, et de construire le schéma en utilisant les objets de notre bibliothèque. L’écriture du schéma XML à plusieurs avantages: il est facile à écrire, permet d’utiliser des outils extérieurs pour l’éditer facilement, et bénéficie, grâce a XML Schema, d’une auto-complétion et d’une vérification à la volée, lors de l’écriture.

Les injecteurs de dépendances Google Juice et Spring permettent l’utilisation des annotations directement dans le code, pour définir les règles d’injection (le schéma pour nous).

Bien qu’il ne s’agisse pas d’un comportement recommandé (les annotations ne sont exploitables que par un type d’injecteur, même si une spécification est actuellement en cours), il est possible d’utiliser la réflexion sur un projet, et de la combiner a l’utilisation d’annotations pour déduire facilement la structure de notre schéma, pour le remplir ensuite à notre guise.

Ce composant est également un monteur.

Les monteurs suivants sont fournis de base:

• Le monteur XML
• Le monteur PHP, qui utilise une interface fluide, pour permettre des configurations de ce type:$monteur->addService()->withMethod()
• Le monteur Réflexion (utilise la réflexion sur nos classes pour construire un schéma)

Dumpers

Un dumper est un objet qui copie des données d’un type de format vers un autre. Effectivement, il peut s’avérer utile d’avoir une manière simple de se représenter un schéma déjà défini.

Les dumpers permettent par exemple de représenter un schéma sous une forme graphique, ou bien sous une forme plus compréhensible pour nous, avec un simple texte par exemple.

Il est donc vraiment facile de montrer les dépendances de vos projets, en utilisant simplement le dumper Dot (qui est le format utilisé par graphviz) par exemple.

Voici la liste des dumpers :

• Le dumper texte
• Le dumper Dot (graphviz)
• Le dumper XML
• Le dumper PHP

Ces deux composants laissent entrevoir des pistes intéressantes: il est possible d’écrire ses classes, puis de générer un schéma partiel grâce au monteur « réflexion» , de le dumper en XML, de le compléter à la main (avec de l’auto-complétion), et de le monter à nouveau, grâce au monteur XML.

Implémentation

Voici quelques règles que nous avons suivi lors du développement en lui même:

Espaces de noms / PHP 5.3

Alors que nous nous penchions sur ce projet, PHP 5.3 n’était pas encore sorti, mais puisque cette version apportait des fonctionnalités vraiment intéressantes (late static binding, espaces de noms et closures), nous avons choisi d’utiliser alors la version en cours de développement de PHP 5.3.

Maintenant, PHP 5.3 est disponible en version stable, et permet de faire fonctionner notre projet.

Notre bibliothèque se sépare selon les espaces de noms suivants:

• L’espace de nomConstruction, qui contient toutes les classes liées au concept de construction (les stratégies de construction)
• L’espace de nomDefinition, qui contient le schéma.
• L’espace de nomTransformationqui contient les Dumpers et les Monteurs

Développement piloté par les tests (TDD)

Ce projet fut également l’occasion d’écrire nos premiers tests, pour finir par utiliser une approche pilotée par les tests.

Le développement piloté par les tests préconise de réaliser ses tests avant d’écrire ses classes. Au début, ça chatouille un peu, mais on comprend rapidement l’intérêt de cette méthodologie, qui est une vraie bonne pratique.

Écrire ses tests avant d’avoir codé la classe nous oblige à la fois à privilégier une utilisation logique de nos composants, et à fixer les interfaces. Le code produit est réellement comme on souhaite l’utiliser, et non pas comme il est plus facile de l’implémenter.

Écrire des tests, c’est aussi penser à l’ensemble des scénarios d’utilisation de ces classes, même les plus farfelus. Cela nous oblige à réfléchir à tous ces cas d’utilisation, et ça fait le plus grand bien !

Pour revenir aux tests, ils permettent de tester que notre application se comporte bien comme elle le devrait, mais cela permet aussi de détecter rapidement des régressions que de nouvelles fonctionnalités peuvent apporter.

Rapidement, on écrit des tests pour tout: bugs, idées, etc. Ça favorise vraiment le développement d’une application.

Un peu plus haut, je parlais de Mock objets (ou objets bouchon, en français). Je vous laisse consulter l’article wikipédia sur les mocks pour vous faire une idée plus précise, mais il s’agit, rapidement, d’objets qui permettent de simuler le comportement d’autres objets, ces derniers pouvant communiquer avec la suite de tests.

Interfaces

Dans l’ensemble de nos classes, nous essayons d’utiliser des interfaces plutôt que des implémentations particulières.
Pourquoi ? Parce que travailler avec des interfaces nous permet de changer à tout moment d’implémentation !

Dans le cas d’Alice, elle n’est pas dépendante d’un type particulier de glace (celle à la fraise), mais simplement aux glaces, à l’interfaceGlace, pour être exact.

Chacune des interfaces ci dessous représente un comportement décrit plus haut:

• Schema
• Service
• Method
• Argument
• Container
• Dumper
• Builder

L’écriture des classes

Pour écrire nos classes, et parce que nous souhaitons fournir un système facilement extensible, nous fournissons quasi systématiquement une interface, et une classe abstraite, pour que chaque concept puisse être étendu facilement.

D’ailleurs, l’écriture des classes en elle même est assez simple, une fois que tous les concepts ont étés décrit et sont clairs.

Vous pouvez regarder le code sur le dépôt mercurial de spiral

Je ne vois pas grand chose à ajouter à propos de l’implémentation, si ce n’est, peut être, qu’il est indispensable de commenter votre code: cela permet aux potentiels futur contributeurs de s’y retrouver facilement, et de comprendre le détail des opérations !

Conclusion

J’espère que cet article vous aura intéressé, en tout cas j’ai pris beaucoup de plaisir à l’écrire, et vous aurez au moins appris comment nous avons choisi d’implémenter un injecteur de dépendances en utilisant quelques bonnes pratiques logicielles !

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 !