Ravi de vous rencontrer. Je suis encore un jeune avec moins de 2 ans d'expérience en tant que programmeur, mais je sortirai progressivement ce que j'ai étudié. Si vous avez des erreurs, veuillez nous en informer.
Pour le moment, je vais résumer brièvement ce que j'ai appris sur DI (conteneur DI qui l'implémente), qui est le système central du framework Java que j'ai utilisé jusqu'à présent, également comme test de publication.
Abréviation de Dependency Injection. Un modèle de conception de logiciel qui réalise le principe de l'IOC (Inversion of Control). Définition d'une classe (temporairement appelée classe de composant) requise pour une certaine classe (temporairement appelée classe d'interface) (cette opération de paramétrage est également appelée "injection"). En utilisant DI, il est possible de séparer la génération et les dépendances des instances qui composent la logique de la classe d'interface.
Au fur et à mesure que l'échelle du développement d'applications augmente, une logique est souvent implémentée en combinant plusieurs classes de composants. Lorsque cela se produit, le degré de connexion des classes augmentera progressivement et le coût du changement dû au remplacement partiel de l'implémentation augmentera.
//Classe d'interface qui gère le traitement lié à l'utilisateur
public class UserServiceImpl implements UserService {
//Classe de composant liée à la persistance des données
private UserRepository userRepo;
private AddressRepository addressRepo;
/*constructeur*/
public UserServiceImpl() {
this.userRepo = new UserRepositoryImpl();
this.addressRepo = new AddressRepositoryImpl();
}
}
Lors de l'implémentation d'une telle classe, il est nécessaire d'avoir les classes de composants (UserRepositoryImpl et AddressRepositoryImpl) à l'avance. Si ceux-ci sont incomplets, vous utiliserez probablement une classe factice, mais à mesure que l'échelle de développement grandit, vous pouvez même remplacer la classe factice. Le coût du changement augmentera.
Afin de réduire le degré de couplage de telles classes, implémentons-le sur la base du concept de DI. Plus précisément, il est possible d'arrêter d'instancier la classe de composant à l'intérieur de la classe d'interface et de recevoir l'interface de la classe de composant comme argument.
Java.UserServiceImpl
/*constructeur*/
public UserServiceImpl(UserRepository userRepo,AddressRepository addressRepo) {
this.userRepo = userRepo;
this.addressRepo = addressRepo;
}
Java.Traitement des appels UserService
UserRepository userRepo = new UserReposiotryImpl();
AddressRepository addressRepo = new AddressRepositoryImpl();
UserService userService = new UserServiceImpl(userRepo,addressRepo);
Cela permet à l'appelant de remplacer la classe d'implémentation factice et de composant sans modifier l'intérieur de UserServiceImpl. Cependant, même avec l'implémentation ci-dessus, le paramétrage de chaque classe de composant pour la classe d'interface sera effectué manuellement et le coût de modification reste élevé. Si possible, j'aimerais également automatiser tous ces paramètres. Le conteneur DI rend cela possible.
La plate-forme qui exécute automatiquement DI est appelée un conteneur DI. La classe d'appelant de l'interface (appelée classe d'appelant) ne configure ni n'implémente manuellement la classe d'interface comme décrit ci-dessus. Vous pouvez obtenir une instance de la classe d'interface avec la classe de composant définie via le conteneur DI. Bien sûr, si une classe de composant dépend d'une autre classe de composant, elle la configurera également.
//Implémentation par la fonction conteneur DI de Spring
//Terminé tous les paramètres liés au conteneur DI à l'avance
public class UserServiceImpl implements UserService {
@Inject
private UserRepository userRepo;
@Inject
private AddressRepository addressRepo;
}
Résolution des dépendances: les dépendances entre la classe d'interface et la classe de composant peuvent être résolues Le contrôle de la portée est possible: le délai entre l'instanciation et la destruction de la classe de composant peut être défini individuellement. Il est possible de contrôler que certaines classes de composants sont réutilisées en tant qu'objets singleton et que certaines classes de composants sont nouvellement créées à chaque fois. Fourniture d'AOP: lors de la récupération d'une classe de composant à partir d'un conteneur DI, un traitement commun peut être inséré de manière uniforme. De plus, le contrôle du cycle de vie est possible etc ...
La relation entre une classe d'interface et une classe de composant est relative, et il est tout à fait possible qu'une classe qui est une classe d'interface pour une classe soit une classe de composant pour une autre classe.
Recommended Posts