Dipendenze non utilizzate e iniezione del costruttore

Question

Dipendenze non utilizzate e iniezione del costruttore

#1 da (6 voti)

1

Ho una classe con 3 dipendenze.

WritabbleDBConnection, ReadOnlyDBConnection e un oggetto utility QueryFilter.

Voglio fare Injection del costruttore, quindi la mia classe sarebbe simile a questa.

class PersonDataAccessObject {

    public function __construct($dbWrite, $dbRead, $queryFilter) {
        // sets to local vars
    }

    public function A() {} // uses $dbRead

    public function B() {} // uses $dbWrite

}

Questo oggetto molto probabilmente verrà istanziato in un factory statico, che sa come recuperare le connessioni DB.

Il problema che vedo è che ogni volta che costruisco questo oggetto ho bisogno di passare tutte le 3 dipendenze, anche se forse solo una delle verrà usata per le operazioni che dovrò fare.

Non mi piace nascondere le mie dipendenze all'interno di una classe di localizzazione di servizi, dal momento che voglio mantenere le mie dipendenze esplicite.

Ci sono soluzioni per questo? O devo vivere con istanze inutilizzate?

object-oriented dependency-injection php

posta Patrick Forget 13.08.2013 - 21:43

fonte

1 risposta

Leggi altre domande sui tag object-oriented dependency-injection php

utilizzo di interface.super.print () in java8 Come caricare i clienti per la soluzione basata su AGPL-3?

score 6 · Accepted Answer

Ecco le tre soluzioni che di solito valuto caso per caso:

Utilizza un contenitore o un servizio di localizzazione . Questo è il più veloce perché puoi caricare le dipendenze in modo pigro e chiamare solo ciò che è necessario. Tuttavia, perdi un sacco di testabilità e il tuo codice diventa dipendente da qualcosa a cui non dovrebbe interessare.
Supera tutte le dipendenze in . Questo è più corretto di quanto sopra, ma perdi un po 'di efficienza per una programmazione più chiara.
Dividi la tua classe in modo che ciascuno dei tuoi metodi richieda effettivamente tutte le dipendenze. In molti casi, questo è il modo più puro di fare le cose, ma sfortunatamente può facilmente entrare in modalità di overkill. Non sono sicuro se questo è misurabile o rilevante, ma di solito sono il più felice quando riesco a seguire questa strada.

In genere vado con # 2 o # 3, a meno che non sia assolutamente necessario ho bisogno di accedere a un contenitore. Questo a volte è ok per codice a livello di framework, ma dovrebbe essere evitato nel codice dell'applicazione.