Inversion du contrôle vs injection de dépendance
Selon le papier écrit par Martin Fowler , l’inversion de contrôle est le principe selon lequel le flux de contrôle d’un programme est inversé: au lieu du programmeur contrôlant le flux d’un programme, les sources externes (framework, services, autres composants) ) en prendre le contrôle. C'est comme si on connectait quelque chose à autre chose. Il a cité un exemple concernant EJB 2.0:
Par exemple l'interface Session Bean définit ejbRemove, ejbPassivate (stocké dans la mémoire secondaire), et ejbActivate (restauré à partir de l'état passif ). Vous ne pouvez pas contrôler quand ces méthodes s'appellent, juste quoi ils font. Le conteneur nous appelle, nous ne l'appelle pas.
Cela conduit à la différence entre framework et library:
L'inversion de contrôle est un élément clé de Qu'est-ce qui rend un cadre différent d'un bibliothèque. Une bibliothèque est essentiellement un ensemble de fonctions que vous pouvez appeler, ces journées sont généralement organisées en Des classes. Chaque appel fait du travail et renvoie le contrôle au client.
Je pense que le point de vue que DI est IOC signifie que la dépendance d'un objet est inversée: au lieu de cela, elle contrôle ses propres dépendances, son cycle de vie ... quelque chose d'autre le fait pour vous. Mais, comme vous me l'avez dit de DI à la main, DI n'est pas nécessairement IOC. Nous pouvons toujours avoir DI et pas de CIO.
Cependant, dans cet article (tiré de la pococapsule, un autre framework IOC pour C/C++), il est suggéré qu'en raison de IOC et de DI, les conteneurs IOC et les infrastructures DI sont bien supérieurs. J2EE, car J2EE mélange le code de structure aux composants, ce qui ne le rend pas tout simplement un ancien objet Java/C++ (POJO/POCO).
Inversion des conteneurs de contrôle autres que le modèle d'injection de dépendance (lien d'archivage)
Lecture supplémentaire pour comprendre quel est le problème avec l'ancien framework de développement par composants, ce qui conduit au deuxième document ci-dessus: Pourquoi et quoi de l'inversion du contrôle (lien vers les archives)
Ma question: Qu'est-ce que IOC et DI? Je suis confus. Basé sur pococapsule, IOC est quelque chose de plus important que simplement inverser le contrôle entre les objets ou les programmeurs et les frameworks.
IoC est un terme générique signifiant plutôt que de faire en sorte que l'application appelle les méthodes dans un cadre, le cadre appelle les implémentations fournies par l'application.
DI est une forme d'IoC, dans laquelle les implémentations sont transmises à un objet par le biais de constructeurs/installateurs/recherches de service, objet sur lequel l'objet «dépend» pour se comporter correctement.
IoC sans utiliser DI, par exemple, constituerait le modèle Template car l'implémentation ne peut être modifiée que par le biais d'une sous-classification.
DI Frameworks sont conçus pour utiliser DI et peuvent définir des interfaces (ou des annotations en Java) facilitant la transmission des implémentations.
IoC Containers sont des frameworks DI pouvant fonctionner en dehors du langage de programmation. Dans certains cas, vous pouvez configurer les implémentations à utiliser dans les fichiers de métadonnées (XML, par exemple) qui sont moins invasives. Avec certains, vous pouvez faire IoC ce qui serait normalement impossible, comme injecter une implémentation à pointscuts .
Voir aussi ceci Article de Martin Fowler .
En bref, IoC est un terme beaucoup plus large qui inclut, mais ne se limite pas à, DI
Le terme Inversion of Control (IoC) désignait à l'origine tout type de style de programmation dans lequel un cadre global ou une exécution Contrôlait le déroulement du programme.
Avant que DI ait un nom, les gens commençaient à se référer aux frameworks qui gèrent les dépendances sous le nom d'Inversion Of Control Containers, et bientôt, la signification de l'IoC a progressivement dérivé vers ce sens particulier: Inversion du contrôle des dépendances.
Inversion of Control (IoC) signifie que les objets ne créent pas d'autres objets sur lesquels ils s'appuient pour effectuer leur travail. Au lieu de cela, ils obtiennent les objets dont ils ont besoin d'une source externe (par exemple, un fichier de configuration XML).
Injection de dépendance (DI) signifie que cela se fait sans l'intervention d'objet, généralement par un composant cadre qui transmet les paramètres du constructeur et les propriétés définies.
DI est un sous-ensemble de l'IoC
- IoC signifie que les objets ne créent pas d'autres objets sur lesquels ils s'appuient pour effectuer leur travail. Au lieu de cela, ils obtiennent les objets dont ils ont besoin d'un service extérieur (par exemple, fichier xml ou service d'application unique). 2 implémentations d'IoC, que j'utilise, sont DI et ServiceLocator.
- DI signifie que le principe IoC d'obtention d'un objet dépendant se fait sans utiliser d'objets concrets, mais des abstractions (interfaces). Cela rend la chaîne testable pour tous les composants, car les composants de niveau supérieur ne dépendent pas des composants de niveau inférieur, mais uniquement de l'interface. Les simulacres implémentent ces interfaces.
IoC (I nversion o f C ontrol): - Ce terme est générique et implémenté de différentes manières (événements, délégués, etc.).
DI (D ependency I njection): - DI est un sous-type de IoC et est implémenté par injection constructeur, injection setter ou injection interface).
Mais Spring ne prend en charge que les deux types suivants:
- Setter Injection
- La DI basée sur un marqueur est réalisée en appelant des méthodes de définition sur les beans de l'utilisateur après avoir appelé un constructeur sans argument ou une méthode de fabrique statique sans argument pour instancier leur bean.
- Injection constructeur
- La DI basée sur un constructeur est réalisée en appelant un constructeur avec un certain nombre d'arguments, chacun représentant un collaborateur.En utilisant cela, nous pouvons valider que les beans injectés ne sont pas nuls et échouent rapidement (échouent au moment de la compilation et non au moment de l'exécution), donc en démarrant l'application elle-même, nous obtenons
NullPointerException: bean does not exist. L'injection de constructeur est la meilleure pratique pour injecter des dépendances.
- La DI basée sur un constructeur est réalisée en appelant un constructeur avec un certain nombre d'arguments, chacun représentant un collaborateur.En utilisant cela, nous pouvons valider que les beans injectés ne sont pas nuls et échouent rapidement (échouent au moment de la compilation et non au moment de l'exécution), donc en démarrant l'application elle-même, nous obtenons
IOC (Inversion Of Controller) : Donner le contrôle au conteneur pour obtenir une instance de l'objet est appelé Inversion of Control. fais ça pour toi.
DI (Dependency Injection) : La méthode d'injection de propriétés dans un objet est appelée injection de dépendance.
We have three types of Dependency injection
1) Constructor Injection
2) Setter/Getter Injection
3) Interface Injection
Spring ne prend en charge que les injecteurs Constructor et Setter/Getter Injection.
IoC - Inversion de contrôle est un terme générique, indépendant du langage, il ne s'agit en réalité pas de créer les objets mais de décrire le mode de création de l'objet.
DI- L'injection de dépendance est un terme concret dans lequel nous fournissons des dépendances de l'objet au moment de l'exécution en utilisant différentes techniques d'injection, à savoir. Setter Injection, Injection Constructeur ou Injection d'Interface.
Puisque toutes les réponses mettent l’accent sur la théorie, je voudrais illustrer mon propos par une première approche:
Supposons que nous construisions une application qui contienne une fonction permettant d’envoyer des messages de confirmation SMS une fois la commande expédiée . Nous aurons deux classes, l’une étant responsable de l’envoi du SMS (SMSService), et un autre responsable de la capture des entrées utilisateur (UIHandler), notre code se présentera comme ci-dessous:
public class SMSService
{
public void SendSMS(string mobileNumber, string body)
{
SendSMSUsingGateway(mobileNumber, body);
}
private void SendSMSUsingGateway(string mobileNumber, string body)
{
/*implementation for sending SMS using gateway*/
}
}
public class UIHandler
{
public void SendConfirmationMsg(string mobileNumber)
{
SMSService _SMSService = new SMSService();
_SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
}
}
L'implémentation ci-dessus n'est pas fausse, mais il y a peu de problèmes:
-) Supposons que dans l'environnement de développement, vous souhaitez enregistrer les SMS envoyés dans un fichier texte au lieu d'utiliser la passerelle SMS, pour ce faire; nous finirons par changer l'implémentation concrète de (SMSService) par une autre implémentation, nous perdons de la flexibilité et sommes obligés de réécrire le code dans ce cas.
-) Nous finirons par mélanger les responsabilités des classes, notre (UIHandler) ne devrait jamais savoir l’implémentation concrète de (SMSService), cela devrait être fait en dehors des classes à l’aide d’interfaces. Lorsque cela sera implémenté, cela nous donnera la possibilité de changer le comportement du système en échangeant le (SMSService) utilisé avec un autre service fictif implémentant la même interface. Ce service enregistrera les SMS dans un fichier texte au lieu de les envoyer à mobileNumber.
Pour résoudre les problèmes ci-dessus, nous utilisons des interfaces qui seront implémentées par notre (SMSService) et le nouveau (MockSMSService). En gros, la nouvelle interface (ISMSService) exposera les mêmes comportements des deux services que le code ci-dessous:
public interface ISMSService
{
void SendSMS(string phoneNumber, string body);
}
Ensuite, nous allons changer notre implémentation (SMSService) pour implémenter l'interface (ISMSService):
public class SMSService : ISMSService
{
public void SendSMS(string mobileNumber, string body)
{
SendSMSUsingGateway(mobileNumber, body);
}
private void SendSMSUsingGateway(string mobileNumber, string body)
{
/*implementation for sending SMS using gateway*/
Console.WriteLine("Sending SMS using gateway to mobile:
{0}. SMS body: {1}", mobileNumber, body);
}
}
Nous allons maintenant pouvoir créer un nouveau service de maquette (MockSMSService) avec une implémentation totalement différente en utilisant la même interface:
public class MockSMSService :ISMSService
{
public void SendSMS(string phoneNumber, string body)
{
SaveSMSToFile(phoneNumber,body);
}
private void SaveSMSToFile(string mobileNumber, string body)
{
/*implementation for saving SMS to a file*/
Console.WriteLine("Mocking SMS using file to mobile:
{0}. SMS body: {1}", mobileNumber, body);
}
}
À ce stade, nous pouvons modifier le code dans (UIHandler) afin d’utiliser facilement l’implémentation concrète du service (MockSMSService) comme ci-dessous:
public class UIHandler
{
public void SendConfirmationMsg(string mobileNumber)
{
ISMSService _SMSService = new MockSMSService();
_SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
}
}
Nous avons obtenu beaucoup de flexibilité et mis en place une séparation des problèmes dans notre code, mais nous devons néanmoins modifier la base de code pour basculer entre les deux services SMS. Nous devons donc implémenterDependency Injection.
Pour ce faire, nous devons implémenter une modification dans notre constructeur de classe (UIHandler) afin de lui transmettre la dépendance. Ainsi, le code qui utilise (UIHandler) peut déterminer quelle implémentation concrète de (ISMSService) utiliser:
public class UIHandler
{
private readonly ISMSService _SMSService;
public UIHandler(ISMSService SMSService)
{
_SMSService = SMSService;
}
public void SendConfirmationMsg(string mobileNumber)
{
_SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
}
}
Maintenant, le formulaire d'interface utilisateur qui communiquera avec la classe (UIHandler) est responsable de la définition de l'implémentation de l'interface (ISMSService) à utiliser. Cela signifie que nous avons inversé le contrôle, le (UIHandler) n’est plus responsable de décider quelle implémentation utiliser, le code appelant le fait. Nous avons implémenté le principeInversion of Controldont DI est un type.
Le code de formulaire de l'interface utilisateur sera comme ci-dessous:
class Program
{
static void Main(string[] args)
{
ISMSService _SMSService = new MockSMSService(); // dependency
UIHandler _UIHandler = new UIHandler(_SMSService);
_UIHandler.SendConfirmationMsg("96279544480");
Console.ReadLine();
}
}
Mais la documentation du printemps dit qu'ils sont identiques.
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-introduction
Dans la première ligne, "IoC est également appelé injection de dépendance (DI)".
L'inversion de contrôle est un paradigme de conception dans le but de donner plus de contrôle aux composants ciblés de votre application, ceux qui effectuent le travail.
L'injection de dépendance est un modèle utilisé pour créer des instances d'objets sur lesquels s'appuient d'autres objets sans savoir au moment de la compilation quelle classe sera utilisée pour fournir cette fonctionnalité.
Il existe plusieurs techniques de base pour implémenter l'inversion de contrôle. Ceux-ci sont:
- Utiliser un motif d'usine
- Utilisation d'un modèle de localisateur de service
- En utilisant une injection de dépendance de n'importe quel type ci-dessous:
1). Une injection de constructeur
2). Une injection de setter
3). Une injection d'interface
Inversion of Control est un principe de conception générique de l’architecture logicielle qui aide à la création de cadres logiciels modulaires réutilisables et faciles à gérer.
C'est un principe de conception dans lequel le flux de contrôle est "reçu" à partir de la bibliothèque générique-écrite ou du code réutilisable.
Pour mieux le comprendre, voyons comment nous avions l'habitude de coder dans nos premiers jours de codage. Dans les langages procéduraux/traditionnels, la logique applicative contrôle généralement le flux de l'application et "appelle" le code/les fonctions génériques ou réutilisables. Par exemple, dans une application console simple, mon flux de contrôle est contrôlé par les instructions de mon programme, pouvant inclure les appels à certaines fonctions générales réutilisables.
print ("Please enter your name:");
scan (&name);
print ("Please enter your DOB:");
scan (&dob);
//More print and scan statements
<Do Something Interesting>
//Call a Library function to find the age (common code)
print Age
Dans Contrast, avec IoC, les Frameworks sont le code réutilisable qui "appelle" la logique métier.
Par exemple, dans un système Windows, un framework sera déjà disponible pour créer des éléments d'interface utilisateur tels que des boutons, des menus, des fenêtres et des boîtes de dialogue. Lorsque j'écris la logique métier de mon application, ce sont les événements de framework qui appellent mon code de logique métier (lorsqu'un événement est déclenché) et NON l'inverse.
Bien que le code de la structure ne connaisse pas ma logique métier, il saura quand même appeler mon code. Ceci est réalisé en utilisant des événements/délégués, des rappels, etc. Ici, le contrôle de flux est "inversé".
Ainsi, au lieu de dépendre du flux de contrôle sur des objets liés de manière statique, le flux dépend du graphe d'objet global et des relations entre les différents objets.
L'injection de dépendance est un modèle de conception qui met en œuvre le principe IoC pour résoudre les dépendances des objets.
En termes plus simples, lorsque vous essayez d'écrire du code, vous allez créer et utiliser différentes classes. Une classe (classe A) peut utiliser d'autres classes (classes B et/ou D). Les classes B et D sont donc des dépendances de la classe A.
Une simple analogie sera une voiture de classe. Une voiture peut dépendre d'autres classes telles que moteur, pneus et plus encore.
L'injection de dépendance suggère qu'au lieu que les classes de dépendance (classe Car ici) créent ses dépendances (classe Engine et classe Tire), la classe devrait être injectée avec l'instance concrète de la dépendance.
Permet de comprendre avec un exemple plus pratique. Considérez que vous écrivez votre propre TextEditor. Entre autres choses, vous pouvez avoir un correcteur orthographique qui fournit à l’utilisateur une possibilité de vérifier les fautes de frappe dans son texte. Une implémentation simple d'un tel code peut être:
Class TextEditor
{
//Lot of rocket science to create the Editor goes here
EnglishSpellChecker objSpellCheck;
String text;
public void TextEditor()
{
objSpellCheck = new EnglishSpellChecker();
}
public ArrayList <typos> CheckSpellings()
{
//return Typos;
}
}
À première vue, tout semble rose. L'utilisateur va écrire du texte. Le développeur capturera le texte et appellera la fonction CheckSpellings et trouvera une liste de fautes de frappe qu'il montrera à l'utilisateur.
Tout semble bien fonctionner jusqu'au jour où un utilisateur commence à écrire le français dans l'éditeur.
Pour fournir un support pour plus de langues, nous avons besoin de plus de SpellCheckers. Probablement français, allemand, espagnol, etc.
Ici, nous avons créé un code étroitement associé, SpellChecker "anglais" étant étroitement associé à notre classe TextEditor, ce qui signifie que notre classe TextEditor dépend de EnglishSpellChecker. En d'autres termes, EnglishSpellCheker est la dépendance de TextEditor. Nous devons supprimer cette dépendance. De plus, notre éditeur de texte a besoin d'un moyen de conserver la référence concrète de tout vérificateur orthographique en fonction de la discrétion du développeur au moment de l'exécution.
Ainsi, comme nous l'avons vu dans l'introduction de DI, cela suggère que la classe devrait être injectée avec ses dépendances. Ainsi, il devrait être de la responsabilité du code appelant d’injecter toutes les dépendances à la classe/code appelée. Afin que nous puissions restructurer notre code comme
interface ISpellChecker
{
Arraylist<typos> CheckSpelling(string Text);
}
Class EnglishSpellChecker : ISpellChecker
{
public override Arraylist<typos> CheckSpelling(string Text)
{
//All Magic goes here.
}
}
Class FrenchSpellChecker : ISpellChecker
{
public override Arraylist<typos> CheckSpelling(string Text)
{
//All Magic goes here.
}
}
Dans notre exemple, la classe TextEditor doit recevoir l'instance concrète de type ISpellChecker.
Maintenant, la dépendance peut être injectée dans Constructor, une propriété publique ou une méthode.
Essayons de changer notre classe en utilisant Constructor DI. La classe TextEditor modifiée ressemblera à quelque chose comme:
Class TextEditor
{
ISpellChecker objSpellChecker;
string Text;
public void TextEditor(ISpellChecker objSC)
{
objSpellChecker = objSC;
}
public ArrayList <typos> CheckSpellings()
{
return objSpellChecker.CheckSpelling();
}
}
Ainsi, lors de la création de l'éditeur de texte, le code appelant peut injecter le type SpellChecker approprié à l'instance de TextEditor.
Vous pouvez lire l'article complet ici
IOC (Inversion Of Control): Donner le contrôle au conteneur pour obtenir une instance d'objet s'appelle Inversion of Control. Cela signifie qu'au lieu de créer un objet avec nouvel opérateur , laissez le conteneur le faire pour vous.
DI (Dependency Injection): Le transfert des paramètres requis (propriétés) de XML à un objet (dans POJO CLASS) est appelé injection de dépendance.
IOCindique qu'une classe externe gérant les classes d'une application et qu'une classe externe signifie qu'un conteneur gère la dépendance entre les classes d'une application . concept de base deIOCest ce programmeur Vous n'avez pas besoin de créer vos objets mais décrivez comment ils doivent être créés.
Les principales tâches effectuées par le conteneur IoC sont les suivantes: Pour instancier la classe d’application. pour configurer l'objet. pour assembler les dépendances entre les objets.
DIest le processus qui permet de fournir les dépendances d'un objet lors de l'exécution en utilisant l'injection de setter ou l'injection de constructeur.
DI et IOC sont deux modèles de conception qui se concentrent principalement sur la fourniture de couplage lâche entre composants}, ou simplement une façon de découpler la dépendance conventionnelle. les relations entre les objets de sorte que les objets ne soient pas proches les uns des autres.
Avec les exemples suivants, j'essaie d'expliquer ces deux concepts.
Auparavant, nous écrivons du code comme celui-ci
Public MyClass{
DependentClass dependentObject
/*
At somewhere in our code we need to instantiate
the object with new operator inorder to use it or perform some method.
*/
dependentObject= new DependentClass();
dependentObject.someMethod();
}
Avec l'injection de dépendance, l'injecteur de dépendance prend en charge l'instanciation des objets
Public MyClass{
/* Dependency injector will instantiate object*/
DependentClass dependentObject
/*
At somewhere in our code we perform some method.
The process of instantiation will be handled by the dependency injector
*/
dependentObject.someMethod();
}
Le processus ci-dessus consistant à donner le contrôle à un autre (par exemple le conteneur) pour l'instanciation et l'injection peut être qualifié d'inversion de contrôle et le processus dans lequel le conteneur IOC injecte la dépendance pour nous peut être qualifié de dépendance. injection.
IOC est le principe selon lequel le flux de contrôle d'un programme est inversé: au lieu que le programmeur contrôle le flux d'un programme, le programme contrôle le flux en réduisant les coûts pour le programmeur.et le processus utilisé par le programme pour injecter la dépendance est appelé DI
Les deux concepts fonctionnent ensemble et nous permettent d'écrire du code beaucoup plus souple, réutilisable et encapsulé, ce qui en fait un concept important pour la conception de solutions orientées objet.
Recommander également à lire.
Qu'est-ce que l'injection de dépendance?
Vous pouvez également consulter l'une de mes réponses similaires ici
Différence entre l'inversion du contrôle et l'injection de dépendance
IOC (Inversion of Control) est essentiellement un concept de modèle de conception consistant à supprimer et à dissocier les dépendances afin de rendre le flux non linéaire et à laisser le conteneur/ou une autre entité gérer le provisionnement des dépendances. Il s’agit en fait du directeur d’Hollywood «Ne nous appelez pas, nous vous appellerons» . Donc, résumant les différences.
Inversion de contrôle: - Il s’agit d’un terme générique pour découpler les dépendances et en déléguer l’approvisionnement; il peut être implémenté de plusieurs manières (événements, délégués, etc.).
Injection de dépendance: - DI est un sous-type de IOC et est implémenté par injection de constructeur, de poseur ou de méthode.
L'article suivant décrit cela très proprement.
https://www.codeproject.com/Articles/592372/Dependency-Injection-DI-vs-Inversion-of-Control-IO
// ICO, DI, il y a 10 ans, c'était comme ça:
public class AuditDAOImpl implements Audit{
//dependency
AuditDAO auditDAO = null;
//Control of the AuditDAO is with AuditDAOImpl because its creating the object
public AuditDAOImpl () {
this.auditDAO = new AuditDAO ();
}
}
Maintenant avec Spring 3,4 ou plus tard, comme ci-dessous
public class AuditDAOImpl implements Audit{
//dependency
//Now control is shifted to Spring. Container find the object and provide it.
@Autowired
AuditDAO auditDAO = null;
}
Globalement, le contrôle est inversé depuis l'ancien concept de code couplé vers les frameworks tels que Spring qui rend l'objet disponible. Donc, c'est IOC pour autant que je sache et l'injection de dépendance comme vous le savez lorsque nous injectons l'objet dépendant dans un autre objet à l'aide de Constructeur ou de paramètres. Injecter signifie fondamentalement le passer comme argument. Au printemps, nous avons une configuration basée sur XML et les annotations dans laquelle nous définissons un objet de bean et passons l'objet dépendant avec un style d'injection de constructeur ou de setter.
Le concept d'IoC a été entendu à l'époque de la programmation procédurale. C’est pourquoi, dans un contexte historique, IoC a parlé de l’inversion de la propriété de contrôle - C'est-à-dire à qui incombe la responsabilité d'invoquer les fonctions dans l'ordre souhaité - qu'il s'agisse des fonctions elles-mêmes ou de les inverser pour une entité externe.
Cependant, lorsque la OOP est apparue, les gens ont commencé à parler de l'IoC dans OOP où les applications sont concernées par la création d'objets et leurs relations, en dehors du flux de contrôle. Ces applications voulaient inverser la propriété de la création d'objet (plutôt que du contrôle-flux) et nécessitaient un conteneur responsable de la création de l'objet, du cycle de vie de l'objet et de l'injection de dépendances du objets d'application, éliminant ainsi les objets d'application de la création d'un autre objet concret.
Dans ce sens, DI n’est pas la même chose que Io C, car il ne s’agit pas de contrôle-flux, mais c’est une sorte de Io * , c'est-à-dire l'inversion de propriété de la création d'objet.
Qu'est-ce qui ne va pas dans ma façon d'expliquer DI et IoC?
En ce qui concerne cette question, je dirais que le wiki a déjà fourni des explications détaillées et faciles à comprendre. Je citerai simplement le plus significatif ici.
Dans la programmation orientée objet, il existe plusieurs techniques de base pour implémenter l'inversion de contrôle. Ceux-ci sont:
- Utilisation d'un modèle de localisateur de service Utilisation de l'injection de dépendance, par exemple Injection de constructeur Injection de paramètres Injection de Setter Injection d'interface;
- Utiliser une recherche contextualisée;
- Utilisation de modèle de conception de méthode de modèle;
- Utilisation d'un modèle de conception de stratégie
Quant à Injection de dépendance
l'injection de dépendance est une technique par laquelle un objet (ou une méthode statique) fournit les dépendances d'un autre objet. Une dépendance est un objet utilisable (un service). Une injection est le passage d'une dépendance à un objet dépendant (un client) qui l'utiliserait.
Commençons par D de SOLID et examinons DI et IoC du livre de Scott Millett "Professional ASP.NET Design Patterns":
Principe d'inversion de dépendance (DIP)
LeDIPconsiste à isoler vos classes du béton les implémentations et les avoir dépendent de classes abstraites ou interfaces. Il favorise le mantra du codage à une interface plutôt qu’une implémentation, ce qui augmente la flexibilité au sein d’un système de s'assurer que vous n'êtes pas étroitement associé à une implémentation.
Injection de dépendance (DI) et inversion de contrôle (IoC)
Le principe ID et le principe IoC sont étroitement liés au DIP.DIest l'acte de fournir une classe inférieure ou dépendante via un constructeur, méthode ou propriété. Utilisés conjointement avec DI, ceux-ci les classes dépendantes peuvent être inversées en interfaces ou en classes abstraites cela conduira à des systèmes faiblement couplés, hautement testables et facile à changer.
Dans IoC , le flux de contrôle d’un système est inversé par rapport à la programmation procédurale. Un exemple de ceci est un IoC conteneur , dont le but est d'injecter des services dans le code client sans avoir le code client spécifiant l'implémentation concrète . Le contrôle dans ce cas qui est inversé est l'acte de client obtenant le service.
Millett, C (2010). Modèles de conception professionnels ASP.NET. Wiley Publishing. 7-8.
1) DI est Child-> obj dépend de parent-obj. Le verbe dépend est important . 2) IOC est Child-> obj exécuter sous une plateforme. où la plate-forme pourrait être école, collège, cours de danse. Ici, effectuer est une activité avec une implication différente sous n'importe quel fournisseur de plate-forme.
exemple pratique: `
//DI
child.getSchool();
//IOC
child.perform()// is a stub implemented by dance-school
child.flourish()// is a stub implemented by dance-school/school/
`
-UN B
J'ai trouvé le meilleur exemple sur Dzone.com qui est vraiment utile pour comprendre la différence réelle entre IOC et DI
"IoC, c'est quand quelqu'un d'autre crée des objets pour vous." Ainsi, au lieu d'écrire "nouveau" mot clé (par exemple, MyCode c = new MyCode ()) dans votre code, l'objet est créé par quelqu'un d'autre. Ce «quelqu'un d’autre» est normalement appelé conteneur IoC. Cela signifie que nous transférons la responsabilité (contrôle) au conteneur pour obtenir une instance d'objet appelée Inversion of Control., signifie qu'au lieu de créer un objet à l'aide d'un nouvel opérateur, laissez le conteneur le faire pour vous.
DI(Dependency Injection): Way of injecting properties to an object is
called
Dependency injection.
We have three types of Dependency injection
1) Constructor Injection
2) Setter/Getter Injection
3) Interface Injection
Spring will support only Constructor Injection and Setter/Getter Injection.