Not My Idea » Injection de dépendances http://www.notmyidea.org Carnets Web d'Alexis Métaireau Tue, 20 Jul 2010 10:07:17 +0000 http://wordpress.org/?v=2.8 en hourly 1 Injection de dépendances – Utilisation du SpiralDi Container http://www.notmyidea.org/article/fr-introduction-to-spiral-dependency-injection-container-in-php/ http://www.notmyidea.org/article/fr-introduction-to-spiral-dependency-injection-container-in-php/#comments Tue, 23 Jun 2009 09:05:38 +0000 Alexis Metaireau http://www.notmyidea.org/?p=189 Cet article est également disponible en version anglaise. Un grand merci à Frédéric Sureau pour son travail de traduction.

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

  1. Tour d’horizon
  2. Principes
    1. Portée des services (Scopes)
  3. Utilisation « avancée» 
    1. Utilisation des Références et des MethodFactory
    2. Héritage et surcharge de services
    3. Container Aware
  4. Factories
  5. Téléchargez le !
    1. Via le dépôt mercurial
    2. Via les archives
  6. Et ailleurs ?
  7. Lectures intéressantes

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:

< ?xml version="1.0" encoding="UTF-8"?>
<container>
    <service name="db" class="Database">
        <constructor>
            <argument value="localhost"/>
            <argument value="root"/>
            <argument value="password"/>
        </constructor>
    </service>
    <service name="user" class="User">
        <method name="setDb">
            <argument type="service" value="db"/>
        </method>
    </service>
</container>

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

$builder = new SpiralDi_SchemaBuilder_Xml();
$builder->setFileName("schema.xml");
$schema = $builder->buildSchema();

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:

// construction du conteneur
$container = new SpiralDi_Container_Default($schema);

// récupération du service souhaité
$myUser = $container->user;

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é

scope="prototype"

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:

$config = new Config();
$service = new Db($config->host, $config->user, $config->password);

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

<service name="db" class="Database">
    <constructor>
        <argument ref="config" value="host"/>
        <argument ref="config" value="user"/>
        <argument ref="config" value="password"/>
    </constructor>
</service>

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

getParam()

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

$config = new Config();
$service = new Db(
    $config->getParam("host"),
    $config->getParam("user"),
    $config->getParam("password")
);

Le code XML est alors le suivant:

<argument ref="config" value="host" factoryMethod="getParam"/>

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.

<service name="extendedService" extends="config">
    <method name="method2">
        <argument value="value"/>
    </method>
</service>

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» :

<service name="containerAwareService" class="Service" containerAware="true"/>
<!-- est exactement équivalent à-->
<service name="containerAwareService" class="Service">
    <method name="setDiContainer">
        <argument type="container" />
    </method>
</service>

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

$service = MyServiceFactory::createService();

Le code XML correspondant est le suivant:

<service name="serviceFactory" type="factory" class="MyServiceFactory">
    <method name="createService" />
</service>

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

<service name="singleton" type="factory" class="Mysingleton">
    <method name="getInstance" />
</service>

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

hg clone https://ametaireau@bitbucket.org/ametaireau/spiraldi/

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 Flow31 leur font d’ailleurs la part belle, et c’est tant mieux! Quelques alternatives possibles au conteneur de Spiral donc:

Lectures intéressantes

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

  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
]]> http://www.notmyidea.org/article/fr-introduction-to-spiral-dependency-injection-container-in-php/feed/ 1 Introduction à l’injection de dépendances: le cas du singleton. http://www.notmyidea.org/article/dependency-injection-singleton-design-pattern-ioc-dendencies-dependences/ http://www.notmyidea.org/article/dependency-injection-singleton-design-pattern-ioc-dendencies-dependences/#comments Mon, 25 May 2009 14:36:58 +0000 Alexis Metaireau http://www.notmyidea.org/?p=67 L’architecture logicielle est un des aspects du développement qui m’intéresse particulièrement. Ça fait d’ailleurs un bout de temps que l’idée d’un article à propos des dépendances (de l’injection de dépendances) et du cas du singleton me trotte dans la tête, alors, le voici:

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, à 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):

class DbConnection_MySql {
    private static $_instance;
    private function __construct () {}

    public static function getInstance () {
        if (!(self::$_instance instanceof self))
            self::$_instance = new self();

        return self::$_instance;
    }
    public function connect(){
        // do some stuff
    }
}

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.

class User{

    public function __construct(){
        // dépendance avec la classe DbConnection
        $dbc = DbConnection_MySql::getInstance();
    }
}

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()1.

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:

$dbc = new DbConnection_Default();
$user = new ClassA_Default();
$user->setDbConnection($dbc);

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

// Interfaces
interface DbConnection {
    function __construct($host, $user, $password);
    function connect();
}

interface User{
    function setDbConnection(DbConnection);
}

// Implementations
class DbConnection_Mysql implements DbConnection{
    public function __construct($host, $user, $password){
        // store parameters into the object
    }
    public function connect(){
        // connect to the database
    }
}

class User_Default implements User{
    public function setDbConnection(DbConnection $dbc){
        // store $dbc into the object
    }
}

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

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:

$container->user

. 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

$fluent
->registerService('user', 'User_Default')
    ->call('setDbConnection')->withServices('dbc')
->registerService('dbc', 'DbConnection_Mysql')
    ->construct()->with('localhost', 'root', '')

Via un fichier XML

<container>
    <service name="user" class="User_Default">
        <method name="setDbConnection">
            <argument type="string" value="dbc" service="true"/>
        </method>
    </service>
    <service name="dbc" class="DbConnection_Mysql">
        <method name="__construct">
            <argument type="string" value="localhost"/>
            <argument type="string" value="root"/>
            <argument type="string" value=""/>
        </method>
    </service>
</container>

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 !
]]> http://www.notmyidea.org/article/dependency-injection-singleton-design-pattern-ioc-dendencies-dependences/feed/ 12