Come gestire i costruttori in classi di dati di grandi dimensioni [duplicati]

7

Diverse volte mi sono imbattuto in situazioni in cui hai qualche tipo di classe di impostazioni che contiene semplicemente una massa di dati. Spesso queste classi non sono semplicemente valide senza almeno la maggior parte dei dati.

Tuttavia un costruttore come questo:

public dataclass (int v1, int v2, int v3, int v4,
      string v5, double v6, string v7, int v8, 
      Internalclass v9, string v10,
      double v11, double v12, int v13, int v14)
{
   this.v1=v1;
   this.v2=v2;
   ...
   this.v14=v14; 
}

sembra che non sia una buona pratica di codice. Ora potrei provare a raggruppare alcune di queste variabili insieme, ma spesso queste variabili hanno senso solo nel contesto della classe dati. Quindi, qual è un buon modo per progettare una classe di dati simile?

    
posta Thijser 09.11.2015 - 13:10
fonte

3 risposte

12

Stai cercando il modello di build .

Essenzialmente è un oggetto con setter in cui puoi impostare i parametri per la costruzione e un metodo createResult() che creerà l'oggetto che stai cercando (o fallirà se non sarebbe valido).

Puoi usarlo per contenere i valori predefiniti per le proprietà e raggrupparne alcuni in un unico setter.

DataClassBuilder builder = new DataClassBuilder();

builder.setV1(v1);
builder.setV3(v3);
builder.setV4(v4);
builder.setV5AndV6(v5, v6);
//...

DataClass data = builder.createResult();
    
risposta data 09.11.2015 - 13:22
fonte
5

Sono richiesti tutti quei parametri effettivamente ? Per "classe dati" intendi un modello di dominio , Visualizza modello o oggetto trasferimento dati ? Richiedere una lista così ampia di argomenti per una semplice "classe di dati" inizia a sentirsi come un odore di codice che ti dice:

  1. Questa classe sta facendo troppo e gran parte del suo lavoro dovrebbe essere delegata ad altre classi che vengono passate come dipendenza

  2. Non è necessario tutto. I valori facoltativi nelle classi di dati non devono essere trasmessi tramite il costruttore

Penso che la domanda qui non sia "Come gestisco un ampio elenco di argomenti del costruttore" e invece "Come posso refactoring il mio modello di oggetto quindi non ho bisogno di due dozzine di parametri per un costruttore."

The Builder Pattern risolverà il tuo problema, ma penso che stia mettendo una benda su un problema più grande che richiede una soluzione diversa.

    
risposta data 09.11.2015 - 14:36
fonte
0

Se i tuoi parametri sono opzionali, il modello Builder potrebbe essere davvero utile! Tuttavia, a volte il modello di costruzione può essere un disastro. Se utilizzi Builder in molti punti, quando aggiungerai un nuovo parametro dovrai assicurarti di non dimenticarti di aggiungerlo in ogni posizione perché non avrai il controllo in fase di compilazione.

Se i parametri non sono opzionali, dovresti verificare che tutto sia stato impostato al momento per chiamare il metodo Build !

Vorrei proporre un'altra soluzione, il Introduci oggetto parametro refactor.

L'idea è di raggruppare i parametri (se possibile) con qualche logica. Quindi, avresti meno parametri nel costruttore questo e forse 3-4 più "classi di parametri". Si potrebbe argomentare che questo sposta il problema altrove, ma offre maggiore flessibilità su come creare questi oggetti parametro.

Forse uno degli "oggetti parametro" può essere creato tramite un factory hardcoded, l'altro può essere recuperato da un file di configurazione, ecc.

In questo modo crei una migliore separazione delle preoccupazioni!

    
risposta data 09.11.2015 - 17:44
fonte

Leggi altre domande sui tag