Le dimensioni del costruttore sono importanti se si utilizza Inversion of Control?

Question

Quindi ho forse 10 oggetti ognuno dei quali ha 1-3 dipendenze (che penso sia ok per quanto riguarda l'accoppiamento lento) ma anche alcune impostazioni che possono essere utilizzate per definire il comportamento (timeout, dimensione della finestra, ecc).

Ora prima di iniziare a utilizzare un contenitore Inversion of Control avrei creato una factory e forse anche un semplice oggetto ObjectSettings per ciascuno degli oggetti che richiede più di 1 impostazione per mantenere le dimensioni del costruttore al valore " meno di 4 " dimensione del parametro. Ora sto usando un'inversione del contenitore di controllo e non riesco proprio a capirlo. Sicuro che potrei ottenere un costruttore con 7 parametri, ma a chi importa? È comunque tutto compilato dall'IoC.

Mi manca qualcosa qui o è sostanzialmente corretto?

Answer 1

La relazione tra la complessità della classe e la dimensione del costruttore IoC non mi era venuta in mente prima di leggere questa domanda, ma la mia analisi di seguito suggerisce che avere molti argomenti nel costruttore IoC è un odore di codice di cui tenere conto quando si utilizza l'IoC. Avere l'obiettivo di attenersi a un breve elenco di argomenti del costruttore ti aiuterà a mantenere semplici le classi. Seguire il principio di responsabilità singola ti guiderà verso questo obiettivo.

Lavoro su un sistema che attualmente ha 122 classi che sono istanziate usando il framework Spring.NET. Tutte le relazioni tra queste classi sono stabilite nei loro costruttori. Certo, il sistema ha la sua giusta dose di codice non perfetto dove ho infranto alcune regole. (Ma, ehi, i nostri fallimenti sono opportunità di apprendimento!)

I costruttori di quelle classi hanno un numero variabile di argomenti, che mostro nella tabella qui sotto.

Number of constructor arguments    Number of classes
           0                             57
           1                             19
           2                             25
           3                              9
           4                              3
           5                              1
           6                              3
           7                              2
           8                              2

Le classi con zero argomenti sono classi strategiche concrete o classi che rispondono agli eventi inviando dati a sistemi esterni.

Quelli con 5 o 6 argomenti sono tutti in qualche modo ineleganti e potrebbero usare alcuni refactoring per semplificarli.

Le quattro classi con 7 o 8 argomenti sono esempi eccellenti di oggetti di Dio . Dovrebbero essere scomposti e ognuno è già nella mia lista di punti problematici all'interno del sistema.

Le restanti classi (da 1 a 4 argomenti) sono (principalmente) progettate semplicemente, facili da capire e conformi alla principio di responsabilità unica .

Answer 2

La necessità di molte dipendenze (forse oltre 8) potrebbe essere indicativa di un difetto di progettazione, ma in generale penso che non ci siano problemi fintanto che il design è coerente.

Inoltre, considera l'utilizzo di un localizzatore di servizi o di un gateway statico per problemi di infrastruttura come la registrazione e l'autorizzazione piuttosto che ingombrare gli argomenti del costruttore.

EDIT: 8 probabilmente sono troppi ma ho pensato che ci sarebbe stato il caso strano. Dopo aver guardato il post di Lee, sono d'accordo, 1-4 di solito è buono.

Answer 3

G'day George,

Prima di tutto, quali sono le dipendenze tra gli oggetti?

Un sacco di " isa " relazioni? Molti "hasa" relazioni?

Un sacco di fan-in? O fan-out?

Risposta di George: "per lo più, ho cercato di seguire la composizione sui consigli sull'ereditarietà ... perché dovrebbe importare però? "

Poiché è principalmente " hasa " dovresti stare bene.

Meglio assicurarsi che la costruzione (e la distruzione) dei componenti sia eseguita correttamente anche se per evitare perdite di memoria.

E, se questo è in C ++, assicurati di usare i distruttori virtuali?

Answer 4

Questo è difficile, e perché preferisco un approccio ibrido in cui le proprietà appropriate sono mutabili e solo le proprietà immutabili e le dipendenze richieste senza un utile default fanno parte del costruttore. Alcune classi sono costruite con gli elementi essenziali, quindi sintonizzate se necessario tramite setter.

Answer 5

Tutto dipende dal tipo di contenitore utilizzato per eseguire il CIO e dagli approcci adottati dal contenitore se utilizza annotazioni o file di configurazione per saturare l'oggetto da installare. Inoltre, se i parametri del costruttore sono solo semplici tipi di dati primitivi, non è un grosso problema; tuttavia, se hai tipi non primitivi, a mio avviso, puoi usare il DI basato sulla proprietà piuttosto che il DI basato sul consutructor.