Come far comprendere al mio IDE il Dependency Injection Container

13 Ott

Out Of Date Warning

Questo post è stato pubblicato più di 2 anni fa (il 13 ottobre 2013). Le idee vanno avanti velocemente, le prospettive cambiano quindi i contenuti potrebbero non essere aggiornati. Ti prego di tenere in considerazione questo, e di verificare le informazioni tecniche presenti nell'articolo prima di farne affidamento per i tuoi scopi.

Recentemente in un mio progetto con Zend Framework 1 ho implementato Pimple, il noto DIC progettato da Fabien Potencier.
Una delle lacune di ZF1, difatti, è la mancanza di un meccanismo interno di supporto alla Dependency injection.

Il problema

In giro ci sono altri DIC ben costruiti, tuttavia la mia scelta e caduta su Pimple grazie alla sua semplicità di utilizzo ed alla sua robustezza (nochè alla fiducia sull’autore nonostante non sia un “Symfoniano”).

Tuttavia quando si lavora con Pimple ci si accorge subito di un problema, l’impossibilità di usare l’autocompletamento con l’IDE.
Difatti a causa dell’astrazione offerta dal DIC, l’IDE che sto usando (Netbeans) non capisce più quello che sta succedendo nel mio codice.
Non capisce ad esempio che $container['myService'] contiene un oggetto.

Questo per me è realmente un bel problema. Programmare senza suggerimenti sul codice e completamento automatico non è piacevole ed il mio IDE diventa inutile.

Soluzioni

Niente panico, vediamo un paio di soluzioni attraverso le quali possiamo risolvere il problema.

Suggerimento del tipo di variabile.

Attraverso i commenti possiamo definire dei DataType inserendoli prima della variabile in questo modo:

In questo modo il mio IDE sarà in grado di sapere che la var $myService contiene un oggetto di tipo MyService.
Tenete presente che questa sintassi funziona con NetBeans. Non ho testato altri IDE come PHPStorm o ZendStudio ma dovrebbero permettere di usare commenti compatibili con PHPDoc quindi ancora meglio:

Sottoclassare il container

La seconda soluzione prevede di sottoclassare Pimple.
In questo modo possiamo superare il limite imposto dal container che funziona come gli array, creando delle funzioni di accesso agli oggetti di primo livello di cui abbiamo bisogno.

Questa soluzione a mio avviso sarebbe quella da preferire, ove possibile, visto che ci dà la possibilità di usare un metodo (quindi sfruttare l’autocompletamento anche sul container) al posto di una chiave di array facile da dimenticare.

Lascia un commento