dipendenze nascoste - perché no?

Question

dipendenze nascoste - perché no?

#1 da (5 voti)

3

Dipendenze nascoste:

function __construct($dep_registry){
  $this->db = $dep_registry->get('db');
  $this->request = $dep_registry->get('request');
  ...
}

Non così nascosto:

function __construct(Db $db, Request $request, ....){
  $this->db = $db;
  $this->request= $request;
  ...
}

Gli svantaggi degli ultimi sono che, se ho bisogno di cambiare la classe più tardi e ho bisogno di un'altra dipendenza, devo cambiare gli argomenti del costruttore. E se cambio il costruttore, devo anche cambiare ogni file che lo usa. Con i deps nascosti la modifica sarebbe necessaria solo nelle due posizioni: il costruttore e la classe di registro. Un altro errore del secondo metodo è che non è possibile alle dipendenze del carico pigro, devo sempre passare le istanze

Quindi qual è lo svantaggio dei dee nascosti e perché è più grande di questo svantaggio di quelli non così nascosti?

If you are using true Inversion of Control, then you shouldn't need to. If you need to add another dependency to the class, you should look back at what this class is doing. Perhaps you need a sub type instead. Adding dependencies could be an indication that you are breaking the Open-Closed Principal of programming (Open for extension, but closed for Modification).

OK, le dipendenze non dovrebbero essere nascoste era / è anche un principio. I principi sono tutti carini e tutti, ma cosa risolvono in realtà, oltre a non violare altri principi? Quindi, perché rompere il principio di Open-Closed cattivo (assumendo che questo è ciò che aggiunge un altro argomento al costruttore))

object-oriented dependency-injection php dependency-management

posta Elfy 26.03.2015 - 18:05

fonte

1 risposta

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

Per un repository SQL concreto, dovrei incapsulare la logica SQL all'interno o all'esterno dei metodi del repository? La modifica di un disegno in seguito lungo la traccia sembra richiedere molto tempo per il suo valore

score 5 · Answer 1

Come outsider che guarda questo codice, non è chiaro come le "dipendenze nascoste" vengano create per cominciare. Cosa succede se non viene registrata alcuna dipendenza "db"? Fa un'eccezione, restituisce null? Se la mia classe non ha una dipendenza "db", quanto è grave?

Molte volte le persone si inclinano verso questo modello quando ci sono troppe dipendenze da passare nel costruttore senza fare apparire il costruttore come una spazzatura completa. Se la tua classe richiede un gran numero di dipendenze, considera invece l'uso di "setter injection" (per una proprietà chiamata "foo", chiama "setFoo (...)" per iniettare tale dipendenza). Risolvi gli argomenti del costruttore per quelle dipendenze che sono assolutamente necessarie solo per avere l'oggetto esistente - non per usare l'oggetto, ma solo per farlo esistere.

Solleva anche la domanda, questa classe sta facendo troppo? Hai davvero bisogno di alcune di queste dipendenze iniettate? C'è un equilibrio tra l'iniezione di dipendenza e l'accoppiamento. Troppo lontano in entrambi i casi e crei mal di testa per te.

Fine, but that still doesn't answer the question. Consider my class only has 1 argument, and on month later I need to add the 2nd one. So I still need to update the 346253453245 files that use my class, right?

Se stai usando True Inversion of Control, non dovresti averne bisogno. Se è necessario aggiungere un'altra dipendenza alla classe, si dovrebbe guardare indietro a ciò che questa classe sta facendo. Forse hai bisogno di un sottotipo invece. L'aggiunta di dipendenze potrebbe indicare che stai interrompendo il Principal di programmazione Open-Closed (aperto per estensione, ma chiuso per modifica).

Non è detto che non puoi modificare una classe una volta scritta, ma non devi modificare l'uso previsto di quella classe - è lo scopo.

L'aggiunta di una nuova dipendenza mi dice che lo scopo di questa classe è cambiato, ed è probabile che tu debba rompere la classe in altre classi, o creare una classe figlia che estenda quella originale. In questo modo il codice esistente che non ha bisogno della funzionalità della nuova classe (e della nuova dipendenza) non deve cambiare.