Abbiamo visto, nelle precedenti guide, i vantaggi della programmazione ad oggetti; tuttavia, non è tutto oro ciò che luccica, e occorre precisare che l’Object Oriented Programming ha anche dei problemi che ti troverai a fronteggiare. Quando lavoriamo all’interno di linguaggi di programmazione che utilizzano l’OOP, infatti, uno dei più grandi problemi da affrontare è quello delle dipendenze.
Per fortuna, ci sono dei mezzi che possono aiutarci sotto questo punto di vista: il più famoso è un pattern di progettazione noto come Dependency Injection.

Cosa sono le dipendenze?

Prima di addentrarci nella Dependency Injection, però, è importante capire che cos’è una dipendenza.
Una dipendenza è definibile nella programmazione informatica come un legame esistente tra varie componenti di un’applicazione per cui il funzionamento di una parte “dipende”, appunto, dalla natura e dalla presenza delle altre parti.

Facciamo l’esempio di un computer: sappiamo che non può funzionare senza scheda madre. Questo si traduce con la classe “Computer” (dipendente) che non può funzionare senza la classe “MotherBoard” (dipendenza) e che, quindi, non potremo utilizzare la prima senza coinvolgere necessariamente la seconda.
Un esempio del genere riesce facilmente a veicolare uno degli aspetti critici della presenza delle dipendenze: il nostro progetto sarà molto meno flessibile, impattando negativamente sul riutilizzo di una classe, e, quindi, sulla velocità di sviluppo, sulla qualità e sulla leggibilità del codice.

Cos’è la Dependency Injection?

Una volta assodato cosa sono le dipendenze, possiamo cominciare a parlare del concetto di Dependency Injection. 
Proviamo a tradurre in codice l’esempio del computer di cui sopra:

class Computer {
  public $motherBoard;
  public function __construct($type){
    $this->motherBoard = new MotherBoard($type);
  }
}
$computer = new Computer('ATX');

In questo modo, creare un’istanza di Computer è molto semplice e veloce, ma mostra il fianco in termini di customizzazione.

In relazione a ciò che abbiamo detto prima, è evidente che questo tipo di approccio, che a prima vista può sembrare corretto, porta, inevitabilmente, a delle problematiche. Infatti, così facendo si va a creare, palesemente, la dipendenza all’interno del costruttore. In questo modo la classe Computer è fortemente accoppiata alla sua dipendenza, la classe MotherBoard.
Questo vuol dire che una modifica al costruttore di MotherBoard (l’aggiunta, magari, di altre proprietà) si ripercuoterà a cascata su tutte le istanze della classe Computer.
Inoltre, gli argomenti passati al costruttore di Computer non c’entrano nulla con il suo scope, essendo utilizzati solo da MotherBoard. Di buona norma, infatti, una classe dev’essere responsabile di una sola cosa.
Proviamo, adesso, ad aggiustare il tiro:

class Computer {
  public $motherBoard;

  public function __construct($motherBoard){
    $this->motherBoard = $motherBoard;
  }
}

$motherBoard = new MotherBoard('ATX');
$computer = new Computer($motherBoard);

Abbiamo fatto un bel passo in avanti, andando ad applicare quella che è la forma più comune di Dependency Injection, iniettando direttamente le dipendenze al costruttore della classe (Constructor Injection).
Questo ci da la libertà di modificare MotherBoard senza andare a toccare minimamente la classe Computer.
Possiamo anche rendere più “sicura” la creazione di un’istanza di classe Computer utilizzando quella che viene definita type hinting, ovvero andando a specificare che come argomento di costruzione dell’istanza Computer dev’essere passato, necessariamente, un oggetto di classe MotherBoard.

class Computer {
  public $motherBoard;

  public function __construct(MotherBoard $motherBoard){
    $this->motherBoard = $motherBoard;
  }
}

$motherBoard = new MotherBoard('ATX');
$computer = new Computer($motherBoard);

In questo modo abbiamo un codice molto più facile da leggere e da capire, in quanto attraverso il type hinting, nel caso venisse iniettata una dipendenza non idonea, potremmo accorgercene subito (scatterebbe immediatamente un errore).

In conclusione, seppur presentata in primo luogo come aspetto problematico, in verità, in progetti a lungo termine,con continue evoluzioni, la Dependency Injection dà il meglio di sé ed è per questo che è un design pattern fortemente in trend di questi tempi.
Sicuramente, applicare la Dependency Injection ha dei costi che alle volte è difficile vedere, come quelli di pianificazione dell’applicazione, ma è indubbio che ne valga la pena.
Con classi strettamente accoppiate (il primo esempio del nostro computer), il progetto diviene estremamente complesso da evolvere e da testare, con una semplice modifica su una classe che rischia di inficiare a cascata tutte le altre.

Tirando le somme, la Dependency Injection è uno strumento notevole nel mondo degli sviluppatori php, ma ci raccomandiamo di utilizzarla in modo intelligente.