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 !

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