Numero di parametri per un costruttore

Question

Ho una classe che necessita di 12 parametri da passare al suo costruttore. Quindi penso che ci sia qualcosa di sbagliato nel design di questa classe.

Vorrei chiedere se esiste un modello di progettazione o una raccolta generale di regole riguardanti il ​​design di una classe, in particolare il suo costruttore.

Answer 1

12 parametri sicuramente sembrano troppi per me. Opzioni per ridurre i loro numeri sono:

1. Introduce Parameter Object raggruppando parametri logicamente collegati in un oggetto e passando quell'oggetto posto dei singoli parametri.

2. Introdurre uno Builder (facoltativamente con method chaining). Ciò non riduce la lista dei parametri effettiva ma rende il codice più leggibile ed è particolarmente utile se si hanno diversi scenari di creazione con parametri variabili. Così, invece di

   MyClass someObject = new MyClass(aFoo, aBar, aBlah, aBaz, aBorp, aFlirp, 
        andAGoo); 
   MyClass anotherObject = new MyClass(aFoo, null, null, aBaz, null, null, 
        andAGoo); 
   

   si può avere

   MyClass someObject = new MyClassBuilder().withFoo(aFoo).withBar(aBar) 
        .withBlah(aBlah).withBaz(aBaz).withBorp(aBorp).withFlirp(aFlirp) 
        .withGoo(aGoo).build(); 
   MyClass anotherObject = new MyClassBuilder().withFoo(aFoo).withBaz(aBaz) 
        .withGoo(aGoo).build(); 
   

3. (forse avrei dovuto iniziare con questo ;-) Analizzare i parametri - è tutto di loro realmente bisogno nel costruttore (cioè obbligatorio)? Se un parametro è facoltativo, puoi impostarlo tramite il suo setter normale invece che con il costruttore.

Answer 2

Penso che questo possa essere accettabile quando si utilizza il pattern State per esempio. Tuttavia, potrei suggerire di passare l'oggetto (se appropriato) che quei parametri provengono invece? E poi nel costruttore che carica i dati da esso?

Answer 3

se possibile è possibile raggruppare i parametri per classi e passare le loro istanze al costruttore.

Answer 4

Se la funzione prende undici parametri, probabilmente avete dimenticato un altro

Amo questa frase, perché riassume tutto: Bad progetto richiede cattiva progettazione.

L'ho preso dal libro Standard di codifica C++: 101 regole, linee guida e best practice di Herb Sutter, Andrei Alexandrescu.

Modifica: la citazione diretta è Se si dispone di una procedura con dieci parametri, probabilmente si è perso un po 'di. È esso stesso a quote from Alan Perlis.

Le funzioni con così tanti parametri sono un sintomo di cattiva progettazione. Una delle possibilità è provare a incapsulare parte di questi parametri in un'entità/classe che ha un obiettivo definito. (non una classe di spazzatura che elencerebbe tutti i parametri senza una struttura significativa).

---

Non dimenticate mai il Single Responsibility Principle Di conseguenza, le classi rimangono limitati in termini di dimensioni, e di conseguenza, in numero limitato di paramters membri, e quindi limitato nella dimensione di parametri necessari per i suoi costruttori.Come uno dei commenti seguenti, la classe con così tanti parametri di costruzione può gestire troppi dettagli inutili indipendentemente dal suo obiettivo principale.

---

Uno sguardo a questo è consigliato anche: How many parameters are too many?

Answer 5

12 Parametri, qualcosa è probabilmente sbagliato con il design.

Cosa si fa con i parametri?

• La classe li invia semplicemente ad altri costruttori? Allora forse dovrebbe solo accettare le interfacce per gli oggetti già pronti.
• La classe è grande e fa molte cose con tutti questi parametri? Quindi la classe ha molte responsabilità e dovrebbe accettare classi che si prendono cura dei dettagli.
• Ci sono dei "cluster" nei parametri? Forse alcuni dei parametri sono una classe nella creazione. Incapsularli e dare loro la responsabilità appropriata.

L'alternativa è che si tratta di parametri per una costruzione a basso livello, dalle prestazioni critiche, nel qual caso il design deve semplicemente tornare indietro, ma raramente è così.