Iniezione delle dipendenze in un metodo con altri parametri del metodo

0

Un mio compagno di squadra ha scritto del codice nel modo seguente:

Class Foo implements Job {
// Framework uses type-hinting for dependency injection, only works on the handle() method
// not on other methods
public function handle(Dependency1 $dep1, Dependency2 $dep2) {

    $this->setAlpha($dep1, $dep2);
    $this->setBravo($dep1, $this->someOtherObject);
}

// This function is only called by the handle method
private function setAlpha($dep1, $dep2) {
    // Do something
}

// This function is only called by the handle method
private function setBravo($dep1, Object $otherObject) {
    // Do something
    $this->something = $dep1->something();
}
}

Sto cercando di spiegargli perché è meglio assegnare le dipendenze alle proprietà della classe private or protected e usarle nelle tue funzioni in modo da non inquinare i parametri del metodo con le dipendenze.

Il suo argomento è che è molto più leggibile in questo modo poiché saprai quali sono le dipendenze dei metodi.

La mia argomentazione è che se scrivi i tuoi metodi in questo modo, possono piuttosto essere resi statici che non sono qualcosa di buono. E che se ottieni metodi extra che richiedono queste dipendenze, hai bisogno di un modo diverso di recuperarli

Qualcuno sa se il codice sopra è un buon modo per farlo o dovrebbe essere riscritto alle proprietà della classe e perché?

Non riesco a trovare buone ragioni e vengo a questo StackExchange per ascoltare le tue opinioni

    
posta Mazzy 07.06.2018 - 13:18
fonte

1 risposta

2

Secondo me, a volte hai ragione. Tutto dipende da quanto spesso dep1 e dep2 cambiano.

L'amico ha ragione: è bene limitare il più possibile l'ambito delle dipendenze. Passandoli dentro come parametri si restringe completamente tale ambito. E se la classe è grande, migliora effettivamente la leggibilità.

Hai ragione è che mettere queste dipendenze in campi privati può semplificare il codice mentre riduci il numero di parametri che ogni funzione ha. E poiché le classi non dovrebbero essere grandi, questo approccio può effettivamente migliorare la leggibilità.

Ciò di cui non sono d'accordo con te è la nozione che " possono piuttosto essere resi statici che non sono qualcosa di buono ". Assolutamente questi metodi possono essere resi statici. Hanno le loro dipendenze iniettate tramite parametri, piuttosto che l'accesso a livello globale, quindi sono i primi candidati per essere statici.

Quindi quale approccio scegliere? Se tali dipendenze sono abbastanza stabili per tutta la durata dell'applicazione, quindi iniettarle tramite un costruttore e memorizzarle come campi. In questo modo devi solo passare un oggetto attorno al tuo sistema, Foo . Se tuttavia sono diversi quasi ogni volta che viene chiamato handle , dovresti creare una nuova Foo ogni volta con tale approccio. Quindi, invece, rendili statici e passa le dipendenze tramite parametri.

    
risposta data 07.06.2018 - 13:31
fonte

Leggi altre domande sui tag