Premièrement, la création d’objets apparentés des classes peut effectivement être réalisée par des nouvelles. Cependant, lorsque le projet est trop volumineux et que l’objet a trop de dépendances, il faut écrire beaucoup de nouveau code lors de la construction de l’objet, et il peut y avoir une méthode pour appeler directement l’objet après avoir oublié d’instancier certains objets dépendants, alors il y aura une exception au pointeur nul. Si ce processus est laissé à la gestion du conteneur, nous n’avons pas à nous soucier de l’instanciation des objets, et il n’y aura pas d’exceptions de pointeur nul lors de l’utilisation d’objets dépendants à tout moment, et le code peut être simplifié. Deuxièmement, les attributs utilisés dans le processus d’appel de méthode peuvent être des attributs d’instance ; s’ils sont tous définis comme statiques, qu’en est-il des données utilisées dans la méthode ? Si vous définissez toutes les méthodes comme statiques, alors les propriétés de la classe référencée dans la méthode doivent aussi être définies comme statiques, ce qui équivaut aux attributs globaux, donc il y aura certainement des problèmes de synchronisation des données. En fait, il est logique de réfléchir aux principes de programmation donnés dans le schéma de conception, tous conçus pour construire un code hautement lisible, facile à maintenir et évolutif. Meilleurs voeux!
Il est pratique d’assembler des logiciels sous forme de blocs de construction, et il est pratique de créer des logiciels avec une forte cohésion et un faible couplage (en extrayant les dépendances du code) Le développement collaboratif, le débogage du code (pas besoin d’intégrer des composants ensemble, ils peuvent être testés séparément), et le code créé est plus robuste.
Le développement de projet met l’accent sur une cohésion élevée et un faible couplage, et l’utilisation de l’injection de dépendances permet d’éviter d’utiliser la nouvelle zone de mots-clés pour créer des objets, réduisant ainsi le couplage entre classes
|