Έχω διαβάσει πολλές εξηγήσεις για το Dependency Injection ή το DI (παλαιότερα γνωστό ως Inversion of Control) και τη σχετική αρχή του Χόλιγουντ ("Μην καλέστε μας, θα σας καλέσουμε."). Όλοι τείνουν να είναι ασαφείς, είτε επειδή διερευνούν αμέσως σε πολύ λεπτομερείς εξηγήσεις, είτε συνδέουν την εξήγηση συγκεκριμένα με μια συγκεκριμένη τεχνολογία. Με τέτοιο τρόπο που είτε το σχέδιο έχει χαθεί είτε η απλότητά του είναι. Εδώ είναι η πιο ξεκάθαρη εξήγηση που έχω βρει - ελαφρώς επεξεργασμένη για συντομία (από την πολύ καλή Spring in Action, 2η έκδοση από τον Craig Walls):
"Οποιαδήποτε μη ιδιωτική εφαρμογή αποτελείται από δύο ή περισσότερες κλάσεις που συνεργάζονται μεταξύ τους για να εκτελέσουν κάποια επιχειρηματική λογική. Παραδοσιακά, κάθε αντικείμενο είναι υπεύθυνο για τη λήψη των δικών του αναφορών στα αντικείμενα με τα οποία συνεργάζεται (τις εξαρτήσεις του). Κατά την εφαρμογή DI, το στα αντικείμενα δίδονται οι εξαρτήσεις τους κατά το χρόνο δημιουργίας από κάποια εξωτερική οντότητα που συντονίζει κάθε αντικείμενο στο σύστημα. Με άλλα λόγια, οι εξαρτήσεις εισάγονται σε αντικείμενα. "
Το βρίσκω πολύ σαφές.
Το Dependency Injection ονομάστηκε αρχικά Inversion of Control (IoC) επειδή η κανονική ακολουθία ελέγχου θα ήταν το αντικείμενο να βρει τα αντικείμενα από τα οποία εξαρτάται από μόνη της και στη συνέχεια να τα καλεί. Εδώ, αυτό αντιστρέφεται: Οι εξαρτήσεις παραδίδονται στο αντικείμενο κατά τη δημιουργία του. Αυτό απεικονίζει επίσης την Αρχή του Χόλιγουντ στην εργασία: Μην καλέσετε για τις εξαρτήσεις σας, θα τους δώσουμε όταν σας χρειαζόμαστε.
Εάν δεν χρησιμοποιείτε DI, πιθανότατα αναρωτιέστε γιατί είναι μεγάλη υπόθεση. Παρέχει ένα βασικό πλεονέκτημα: χαλαρή ζεύξη. Τα αντικείμενα μπορούν να προστεθούν και να δοκιμαστούν ανεξάρτητα από άλλα αντικείμενα, επειδή δεν εξαρτώνται από οτιδήποτε άλλο από αυτό που τα περνάτε. Όταν χρησιμοποιείτε παραδοσιακές εξαρτήσεις, για να δοκιμάσετε ένα αντικείμενο πρέπει να δημιουργήσετε ένα περιβάλλον όπου όλες οι εξαρτήσεις του υπάρχουν και είναι προσβάσιμες προτού μπορέσετε να το δοκιμάσετε. Με το DI, είναι δυνατό να δοκιμάσετε το αντικείμενο μεμονωμένα περνώντας τα πλαστά αντικείμενα για αυτά που δεν θέλετε ή δεν πρέπει να δημιουργήσετε. Παρομοίως, η προσθήκη μιας τάξης σε ένα έργο διευκολύνεται επειδή η τάξη είναι αυτόνομη, οπότε αυτό αποφεύγει το "μεγάλο hairball" στο οποίο τα μεγάλα έργα εξελίσσονται συχνά.
Η πρόκληση του DI είναι να γράφει μια ολόκληρη εφαρμογή χρησιμοποιώντας τη. Μερικά μαθήματα δεν είναι μεγάλη υπόθεση, αλλά μια ολόκληρη εφαρμογή είναι πολύ πιο δύσκολη. Για ολόκληρες εφαρμογές, συχνά θέλετε ένα πλαίσιο για τη διαχείριση των εξαρτήσεων και των αλληλεπιδράσεων μεταξύ αντικειμένων. Τα πλαίσια DI οδηγούνται συχνά από αρχεία XML που βοηθούν στον καθορισμό του τι πρέπει να μεταβιβαστούν σε ποιον και πότε. Το Spring είναι ένα πλήρες πλαίσιο Java DI. Άλλα ελαφρύτερα πλαίσια DI περιλαμβάνουν το NanoContainer και το ακόμα πιο ελαφρύ PicoContainer.
Τα περισσότερα από αυτά τα πλαίσια έχουν καλά μαθήματα για να βοηθήσουν τους αρχάριους να βρουν το δρόμο τους.
Αυτή η ιστορία, "Εξαιρετική εξήγηση της έγχυσης εξάρτησης (Inversion of Control)" δημοσιεύθηκε αρχικά από το JavaWorld.
