L'uso del "nuovo" nel costruttore è sempre negativo?

Ho letto che usare "nuovo" in un costruttore (per qualsiasi altro oggetto oltre a quelli di semplice valore) è una cattiva pratica in quanto rende impossibile il test unitario (poiché quindi anche quei collaboratori devono essere creati e non possono essere derisi). Dato che non ho molta esperienza nei test unitari, sto cercando di raccogliere alcune regole che imparerò per prime. Inoltre, questa è una regola generalmente valida, indipendentemente dalla lingua utilizzata?

Ci sono sempre delle eccezioni, e metto in discussione il "sempre" nel titolo, ma sì, questa linea guida è generalmente valida e si applica anche al di fuori del costruttore.

L'uso di new in un costruttore viola la D in SOLID (principio di inversione di dipendenza). Rende difficile testare il tuo codice perché i test unitari riguardano l'isolamento; è difficile isolare la classe se ha riferimenti concreti.

Non si tratta solo di test unitari. Cosa succede se desidero indirizzare un repository a due database diversi contemporaneamente? La possibilità di passare nel mio contesto mi consente di creare un'istanza di due diversi repository che puntano a posizioni diverse.

Non usare new nel costruttore rende il tuo codice più flessibile. Questo vale anche per i linguaggi che possono usare costrutti diversi da quelli newper l'inizializzazione degli oggetti.

Tuttavia, chiaramente, è necessario usare il buon senso. Ci sono molte volte in cui va bene usare new, o dove sarebbe meglio non farlo, ma non avrai conseguenze negative. Ad un certo punto da qualche parte, newdeve essere chiamato. Fai solo attenzione a chiamare newall'interno di una classe da cui dipendono molte altre classi.

Fare qualcosa come inizializzare una collezione privata vuota nel tuo costruttore va bene, e iniettarla sarebbe assurdo.

Più riferimenti ha una classe, più attenta dovresti non chiamarla newal suo interno.

Mentre sono a favore dell'utilizzo del costruttore per inizializzare semplicemente la nuova istanza anziché per creare più altri oggetti, gli oggetti helper sono ok e devi usare il tuo giudizio sul fatto che qualcosa sia un tale helper interno o meno.

Se la classe rappresenta una raccolta, potrebbe avere un array helper interno o un elenco o un hashset. Userebbe newper creare questi aiutanti e sarebbe considerato abbastanza normale. La classe non offre iniezione per utilizzare diversi helper interni e non ha motivo di farlo. In questo caso, si desidera testare i metodi pubblici dell'oggetto, che potrebbero andare ad accumulare, rimuovere e sostituire elementi nella raccolta.

In un certo senso, il costrutto di classe di un linguaggio di programmazione è un meccanismo per creare astrazioni di livello superiore e creiamo tali astrazioni per colmare il divario tra il dominio del problema e le primitive del linguaggio di programmazione. Tuttavia, il meccanismo di classe è solo uno strumento; varia in base al linguaggio di programmazione e, in alcune lingue, alcune astrazioni del dominio richiedono semplicemente più oggetti a livello del linguaggio di programmazione.

In sintesi, è necessario valutare se l'astrazione richiede semplicemente uno o più oggetti interni / di supporto, mentre viene ancora vista dal chiamante come una singola astrazione o se gli altri oggetti sarebbero meglio esposti al chiamante per creare per controllo delle dipendenze, che sarebbe suggerito, ad esempio, quando il chiamante vede questi altri oggetti nell'uso della classe.

Non tutti i collaboratori sono abbastanza interessanti da testare l'unità separatamente, è possibile (indirettamente) testarli attraverso la classe di hosting / istanziazione. Questo potrebbe non allinearsi con l'idea di alcune persone di dover testare ogni classe, ogni metodo pubblico ecc. Specialmente quando si fa il test dopo. Quando si utilizza TDD è possibile effettuare il refactoring di questo "collaboratore" estraendo una classe in cui è già completamente testato dal primo processo di test.

Dato che non ho molta esperienza nei test unitari, sto cercando di raccogliere alcune regole che imparerò per prime.

Fai attenzione a imparare "regole" per i problemi che non hai mai incontrato. Se ti imbatti in qualche "regola" o "migliore pratica", suggerirei di trovare un semplice esempio di giocattolo in cui "si suppone" che questa regola venga utilizzata e di provare a risolvere il problema da solo , ignorando ciò che dice la "regola".

In questo caso, potresti provare a inventare 2 o 3 classi semplici e alcuni comportamenti che dovrebbero implementare. Implementa le lezioni in qualsiasi modo sembri naturale e scrivi un test unitario per ogni comportamento. Fai un elenco di tutti i problemi che hai riscontrato, ad esempio se hai iniziato a lavorare in un modo, poi dovevi tornare indietro e cambiarlo in seguito; se ti sei confuso su come le cose dovrebbero andare insieme; se ti sei infastidito nello scrivere il bollettino; eccetera.

Quindi prova a risolvere lo stesso problema seguendo la "regola". Ancora una volta, fai un elenco dei problemi che hai riscontrato. Confronta gli elenchi e pensa a quali situazioni potrebbero essere migliori quando segui la regola e quali no.

Per quanto riguarda la tua vera domanda, tendo a favorire un approccio di porte e adattatori , in cui facciamo una distinzione tra "logica di base" e "servizi" (questo è simile alla distinzione tra funzioni pure e procedure efficaci).

La logica di base consiste nel calcolare le cose "all'interno" dell'applicazione, in base al dominio del problema. Potrebbe contenere classi come User, Document, Order, Invoice, fine del ecc di avere classi di base richiedono newper le altre classi di base, dato che sono i dettagli "interni" di implementazione. Ad esempio, la creazione di un Orderpotrebbe anche creare un Invoicee un Documentdettaglio di ciò che è stato ordinato. Non c'è bisogno di deriderli durante i test, perché queste sono le cose reali che vogliamo testare!

Le porte e gli adattatori sono il modo in cui la logica di base interagisce con il mondo esterno. Questo è dove le cose come Database, ConfigFile, EmailSender, tempo reale, ecc. Queste sono le cose che rendono difficile il test, quindi è consigliabile crearle al di fuori della logica di base e passarle secondo necessità (con iniezione di dipendenza o come argomenti del metodo, ecc.).

In questo modo, la logica di base (che è la parte specifica dell'applicazione, in cui vive l'importante logica di business, ed è soggetta alla maggior parte dei churn) può essere testata da sola, senza preoccuparsi di database, file, e-mail, ecc. Possiamo semplicemente passare alcuni valori di esempio e verificare di ottenere i valori di output corretti.

Le porte e gli adattatori possono essere testati separatamente, usando simulazioni per il database, il filesystem, ecc. Senza preoccuparsi della logica aziendale. Possiamo semplicemente passare alcuni valori di esempio e assicurarci che vengano memorizzati / letti / inviati / ecc. appropriatamente.

Consentitemi di rispondere alla domanda, raccogliendo quelli che considero i punti chiave qui. Citerò alcuni utenti per brevità.

Ci sono sempre delle eccezioni, ma sì, questa regola è generalmente valida e si applica anche al di fuori del costruttore.

L'uso di new in un costruttore viola la D in SOLID (principal di inversione di dipendenza). Rende difficile testare il tuo codice perché i test unitari riguardano l'isolamento; è difficile isolare la classe se ha riferimenti concreti.

-TheCatWhisperer-

Sì, l'uso di newcostruttori interni spesso porta a difetti di progettazione (ad esempio l'accoppiamento stretto) che rendono il nostro design rigido. Difficile da provare sì, ma non impossibile. La proprietà in gioco qui è la resilienza (tolleranza alle modifiche) ¹ .

Tuttavia, la citazione sopra non è sempre vera. In alcuni casi, potrebbero esserci classi che devono essere strettamente accoppiate . David Arno ha commentato un paio.

Esistono ovviamente eccezioni in cui la classe è un oggetto valore immutabile , un dettaglio di implementazione , ecc. Dove si suppone che debbano essere strettamente accoppiati .

-David Arno-

Esattamente. Alcune classi (ad esempio classi interne) potrebbero essere semplici dettagli di implementazione della classe principale. Questi devono essere testati insieme alla classe principale e non sono necessariamente sostituibili o estensibili.

Inoltre, se il nostro culto SOLID ci fa estrarre queste classi , potremmo violare un altro buon principio. La cosiddetta legge di Demetra . Che, d'altra parte, trovo che sia davvero importante dal punto di vista del design.

Quindi la risposta probabile, come al solito, è dipende . L'uso di newcostruttori interni può essere una cattiva pratica. Ma non sempre sistematicamente.

Quindi, ci serve per valutare se le classi sono dettagli di implementazione (la maggior parte dei casi non lo faranno) della classe principale. Se lo sono, lasciarli soli. In caso contrario, prendere in considerazione tecniche come la composizione principale o l' iniezione di dipendenza da contenitori IoC .

^{1: l'obiettivo principale di SOLID non è rendere il nostro codice più testabile. È per rendere il nostro codice più tollerante alle modifiche. Più flessibile e, di conseguenza, più facile da testare}

^{Nota: David Arno, TheWhisperCat, spero che non ti dispiaccia di averti citato.}

Come semplice esempio, considerare il seguente pseudocodice

class Foo {
  private:
     class Bar {}
     class Baz inherits Bar {}
     Bar myBar
  public:
     Foo(bool useBaz) { if (useBaz) myBar = new Baz else myBar = new Bar; }
}

Dal momento che newè un puro dettaglio di implementazione di Foo, ed entrambi Foo::Bare Foo::Bazfanno parte di Foo, quando i test unitari Foonon hanno senso deridere parti di Foo. Si prendono in giro solo le parti all'esterno Foo durante il test dell'unità Foo.

Sì, l'uso di "nuovo" nelle classi radice dell'applicazione è un odore di codice. Significa che stai bloccando la classe usando un'implementazione specifica e non sarai in grado di sostituirne un'altra. Optare sempre per l'iniezione della dipendenza nel costruttore. In questo modo non solo sarai in grado di iniettare facilmente dipendenze derise durante il test, ma renderà la tua applicazione molto più flessibile, consentendoti di sostituire rapidamente diverse implementazioni se necessario.

EDIT: per downvoter - ecco un link a un libro di sviluppo software che contrassegna "nuovo" come un possibile odore di codice: https://books.google.com/books?id=18SuDgAAQBAJ&lpg=PT169&dq=new%20keyword%20code%20smell&pg=PT169 # v = onepage & q = new% 20keyword% 20code% 20smell & f = false