Suppose que tu as un objet qui veut sauvegarder des données en base de données.
Naturellement tu fera
ObjetQuiPermetAccesBaseDeDonnees o= new ObjetQuiPermetAccesBaseDeDonnees()
o.save (mesDonnees)
C'est ton objet qui appelle ObjetQuiPermetAccesBaseDeDonnees
Bref, tu as codé en dur le nom de l'objet qui te permet de faire de la persistence.
Tu pourrais mettre une interface (mais bien sûr tu mets déjà une interface), mais quand même quand tu vas instancier ton objet, il faudra bien dire quelle est la classe utilisée.
InterfacePersistance o= new ObjetQuiPermetAccesBaseDeDonnees()
Le principe de l'inversion de contrôle (aussi appelé drôlement "syndrôme d'Holywood") est:" Don't call me I call you"
Objet, ne demande pas une instance de ObjetQuiPermetAccesBaseDeDonnees. C'est un moyen extérieur qui va te passer la référence à cet objet- en l'occurence un framework.
Ce framework va lire un fichier xml de config où il y aura écrit : "Voici l'objet que je vais utiliser pour sauvegarder mes données : c'est ObjetQuiPermetAccesBaseDeDonnees"
Autrement dit, tu as défini ce qui relie chacune entre elles chacune des couche qui font ton appli.
Avantage : c'est défini en un seul endroit. Tu veux changer ton appel à une base de données par une gestion via un file système : tu changes la config. Ou tu veux tester ton objet - et pas l'accès à la base de données : au lieu d'utiliser l'objet qui fait l'accès à la base (et qui ets peut-être buggé) tu crées un faux objet (Mock) qui va mimer le comportement attendu - mais que tu veux pas tester.
Avantage aussi : un seul lieu pour centraliser le cycle de vie des objets. En général, un accès en base c'est un singleton. Là, c'est ton framework qui va être responsable de la vie de l'objet , donc de son unicité.
de même tu peux du coup très facilement, par config, quand tu crées un objet, dire d'executer telle méthode (log, sécurité) et ainsi tu implémentes en un seul endroit un comportement général (aop)
[^] # Re: Hasta la revolucion..
Posté par Gabriel . En réponse à la dépêche Brèves Java. Évalué à 9.
Naturellement tu fera
ObjetQuiPermetAccesBaseDeDonnees o= new ObjetQuiPermetAccesBaseDeDonnees()
o.save (mesDonnees)
C'est ton objet qui appelle ObjetQuiPermetAccesBaseDeDonnees
Bref, tu as codé en dur le nom de l'objet qui te permet de faire de la persistence.
Tu pourrais mettre une interface (mais bien sûr tu mets déjà une interface), mais quand même quand tu vas instancier ton objet, il faudra bien dire quelle est la classe utilisée.
InterfacePersistance o= new ObjetQuiPermetAccesBaseDeDonnees()
Le principe de l'inversion de contrôle (aussi appelé drôlement "syndrôme d'Holywood") est:" Don't call me I call you"
Objet, ne demande pas une instance de ObjetQuiPermetAccesBaseDeDonnees. C'est un moyen extérieur qui va te passer la référence à cet objet- en l'occurence un framework.
Ce framework va lire un fichier xml de config où il y aura écrit : "Voici l'objet que je vais utiliser pour sauvegarder mes données : c'est ObjetQuiPermetAccesBaseDeDonnees"
Autrement dit, tu as défini ce qui relie chacune entre elles chacune des couche qui font ton appli.
Avantage : c'est défini en un seul endroit. Tu veux changer ton appel à une base de données par une gestion via un file système : tu changes la config. Ou tu veux tester ton objet - et pas l'accès à la base de données : au lieu d'utiliser l'objet qui fait l'accès à la base (et qui ets peut-être buggé) tu crées un faux objet (Mock) qui va mimer le comportement attendu - mais que tu veux pas tester.
Avantage aussi : un seul lieu pour centraliser le cycle de vie des objets. En général, un accès en base c'est un singleton. Là, c'est ton framework qui va être responsable de la vie de l'objet , donc de son unicité.
de même tu peux du coup très facilement, par config, quand tu crées un objet, dire d'executer telle méthode (log, sécurité) et ainsi tu implémentes en un seul endroit un comportement général (aop)
http://martinfowler.com/articles/injection.html(...)
http://www.dotnetguru.org/articles/dossiers/ioc/ioc.htm(...)