Evitare costruttori con molti argomenti

Quindi ho una fabbrica che crea oggetti di diverse classi. Le possibili classi sono tutte derivate da un antenato astratto. Il factory ha un file di configurazione (sintassi JSON) e decide quale classe creare, a seconda della configurazione dell'utente.

Per raggiungere questo obiettivo, la fabbrica utilizza boost :: property_tree per l'analisi JSON. Cammina attraverso il ptree e decide quale oggetto concreto creare.

Tuttavia, gli oggetti prodotto hanno molti campi (attributi). A seconda della classe concreta, l'oggetto ha circa 5-10 attributi, in futuro forse anche di più.

Quindi non sono sicuro di come dovrebbe apparire il costruttore degli oggetti. Mi vengono in mente due soluzioni:

1) Il costruttore del prodotto si aspetta che ogni attributo sia un parametro, quindi il costruttore finirà con 10+ parametri. Questo sarà brutto e porterà a lunghe righe di codice illeggibili. Tuttavia, il vantaggio è che la factory può analizzare JSON e invocare il costruttore con i parametri corretti. La classe di prodotto non deve sapere che è stata creata a causa della configurazione JSON. Non ha bisogno di sapere che è coinvolto JSON o la configurazione.

2) Il costruttore del prodotto prevede solo un argomento, l'oggetto property_tree. Quindi può analizzare le informazioni necessarie. Se le informazioni sulla configurazione sono mancanti o fuori limite, ogni classe di prodotto può reagire correttamente. La fabbrica non ha bisogno di sapere quali argomenti sono necessari ai vari prodotti. Inoltre, la fabbrica non deve sapere come reagire in caso di configurazione errata. E l'interfaccia del costruttore è unificata e piccola. Ma, come svantaggio, il prodotto deve estrarre le informazioni necessarie da JSON, quindi sa come è costruito.

Tendo a preferire la soluzione 2). Tuttavia, non sono sicuro che questo sia un buon modello di fabbrica. Sembra in qualche modo sbagliato far sapere al prodotto che è stato creato con la configurazione JSON. Dall'altro lato, i nuovi prodotti possono essere introdotti in modo molto semplice.

Qualche opinione su questo?

Non farei l'opzione 2, perché in questo modo hai complicato per sempre la costruzione del tuo oggetto con l'analisi dell'albero delle proprietà boost. Se sei a tuo agio con una classe che ha bisogno di tanti parametri, dovresti essere a tuo agio con un costruttore che ha bisogno di tanti parametri, questa è la vita!

Se la tua preoccupazione principale è la leggibilità del codice, puoi usare il modello builder, è fondamentalmente lo stopgap c ++ / java per mancanza di argomenti con nome. Finisci con cose che assomigliano a questo:

MyObject o = MyObject::Builder()
               .setParam1(val1)
               .setParam2(val2)
               .setParam3(val3)
             .build();

Quindi ora MyObject avrà un costruttore privato, che viene chiamato in Builder :: build. La cosa bella è che sarà l'unico posto in cui dovrai chiamare un costruttore con 10 parametri. La factory dell'albero delle proprietà boost utilizzerà il builder e successivamente se si desidera costruire un MyObject direttamente o da una fonte diversa, si passerà al builder. E il builder fondamentalmente ti consente di nominare chiaramente ogni parametro mentre lo passi, quindi è più leggibile. Questo ovviamente aggiunge un po 'di boilerplate, quindi dovrai decidere se ne vale la pena rispetto al solo chiamare il costruttore disordinato, o raggruppare alcuni dei parametri esistenti in strutture, ecc. Basta lanciare un'altra opzione sul tavolo.

https://en.wikipedia.org/wiki/Builder_pattern#C.2B.2B_Example

NON utilizzare il secondo approccio.

Non è sicuramente la soluzione e porterebbe solo a creare un'istanza delle classi nella logica aziendale, anziché nella parte dell'app in cui si trovano le fabbriche.

O:

• prova a raggruppare alcuni parametri che sembrano rappresentare cose simili in oggetti
• dividere la classe corrente in più classi più piccole (avere una classe di servizio con 10 parametri sembra che la classe faccia troppe cose)
• lascialo così com'è, se la tua classe non è in realtà un servizio, ma un oggetto valore

A meno che l'oggetto che si sta creando non sia effettivamente una classe che è responsabile della conservazione dei dati, si dovrebbe provare a rifattorizzare il codice e dividere la classe grande in classi più piccole.

L'opzione 2 è quasi giusta.

Un'opzione migliorata 2

Creare una classe "frontale" che ha il compito di prendere quell'oggetto con struttura JSON e selezionare i bit e chiamare i costruttori di fabbrica. Prende ciò che la fabbrica produce e lo dà al cliente.

• La fabbrica non ha assolutamente idea che esista una cosa del genere JSON.
• Il client non deve sapere quali bit specifici sono richiesti dalla fabbrica.

Fondamentalmente il "front-end" sta dicendo ai 2 Bob: "Ho a che fare con i clienti redatte in modo che gli ingegneri non debbano farlo! Ho le competenze delle persone!" Povero Tom. Se solo avesse detto "Ho disaccoppiato il cliente dalla costruzione. Questo risultato è una fabbrica altamente coesa"; avrebbe potuto mantenere il suo lavoro.

Molti argomenti?

Non per il client - comunicazione front-end.

Front-end - fabbrica? Se non 10 parametri, il meglio che puoi fare è rimandare la decompressione, se non la cosa JSON originale, allora un po 'di DTO. È meglio che passare il JSON alla fabbrica? Stessa differenza dico io.

Considererei fortemente il passaggio di singoli parametri. Attenersi all'obiettivo di una fabbrica pulita e coerente. Evita le preoccupazioni della risposta di @DavidPacker.

Mitigare "troppi argomenti"

• Costruttori di fabbrica o di classe

  • prendendo solo argomenti per la costruzione specifica di classe / oggetto.
  • parametri di default
  • parametri opzionali
  • argomenti denominati

• Raggruppamento di argomenti front-end

  • Esamina, valuta, convalida, imposta, ecc. I valori degli argomenti guidati dalle firme del costruttore sopra.