Opzioni per la costruzione di un oggetto che non è inizializzato logicamente fino a quando non vengono impostati tutti i campi

Il pattern Builder è molto utile quando il prodotto che stai costruendo consiste di più parti discrete, dove le informazioni esterne specificano quali parti, o se il prodotto ha molte proprietà opzionali .

Nel tuo caso, hai una lunga lista di proprietà richieste . Qui il modello Builder ti dà solo l'aspetto di un costruttore meno complesso a costo di non essere in grado di rilevare in fase di compilazione che una proprietà è stata persa.
Stai essenzialmente scambiando codice come questo

type1 property1 = ...
type2 property2 = ...
type3 property3 = ...
.
.
.
typeN propertyN = ...
Species x = new Species(property1, property2, property3, ..., propertyN);

per

Builder builder;
builder.setProperty1(...);
builder.setProperty3(...);
.
.
.
builder.setPropertyN(...);
Species x = builder.build();

La costruzione delle specie sembra deliziosamente semplice, ma quanto ci vorrà per capire perché questo codice non funziona?

So che ci sono linee guida che i metodi non dovrebbero prendere più di 3 (o 4) argomenti. Tuttavia, c'è un motivo per cui tutte le lingue nell'uso pratico non lo impongono come un limite difficile: a volte hai solo bisogno di più argomenti. Se anche il più aggressivo raggruppamento di argomenti in oggetti parametro non può farti abbassare di 6 o 7 parametri, ne hai solo bisogno.

There is no way to logically group these into different objects to reduce the amount of parameters passed into the constructor.

Penso che questa sia l'essenza del tuo problema.

Innanzitutto, il modello Builder viene normalmente utilizzato in questa situazione come best practice. Tuttavia, per me personalmente, non mi piace e addirittura lo considero un modello anti. Anche tu in qualche modo, altrimenti non lo chiederesti qui, giusto? ;)

Quindi, mi sento come se alcune proprietà fossero ancora raggruppate. Tuttavia, un buon raggruppamento logico è una delle decisioni di progettazione più difficili. Quindi partiamo dalle informazioni fornite (ho rimosso la finale per facilitare la lettura):

String id,
String name,
Type  primaryType,
Type secondaryType,
StatSet baseStats,
StatSet evPointYield

Ecco che immediatamente mi vengono in mente le coppie di caratteri. Mentre id e name sembrano essere raggruppati, servono a scopi diversi (identificativo e visualizzazione). Quindi non raggruppare qui, hai ragione.

I Type s e StatSet s hanno comunque lo stesso scopo: essi e solo loro influenzano il modo in cui le specie si comportano nelle interazioni di gioco. Raggrupperei quindi tutti questi elementi in un oggetto Behaviour generale. Le sue proprietà possono essere ulteriormente raggruppate. Type s potrebbe essere raggruppato in un oggetto TypeStats . Il StatSet s sembra essere usato solo in combattimento, quindi sarebbe il combatStats . I nomi non sono scelti al meglio qui, lo ammetto.

Questo ha alcuni vantaggi. Ora puoi condividere un comportamento comune tra specie diverse se lo desideri. Puoi assicurarti che quando crei TypeStats non ce ne sia nessuno in cui sia il primo che il secondo tipo sono uguali. Questa dovrebbe essere una preoccupazione del TypeStats non del Species secondo me. È anche più facile spiegare la classe:

Species contain an Id by which they are identified unique. When playing, they are displayed to the user by their names, depending on the country. Each Species also has their own behaviour in this game. This behaviour consists of how it behaves in combats and what you can do with it when not in combat.

Tuttavia, la mia risposta potrebbe essere incompleta o anche parzialmente errata, a seconda del significato delle proprietà che hai menzionato e di quelle che non hai menzionato.

Un ultimo punto: non rendere il tuo secondo tipo null . Questo non è davvero buono. Se usi Java 8, vai alla classe Optional . Se usi Java al di sotto di 7, dai un'occhiata alla libreria googles guava che ti fornisce una classe di questo tipo.

In momenti come questo cerco di fare un passo indietro, dimenticare l'implementazione e concentrarmi sui requisiti.

In sostanza, si desidera:
- Definire entità discrete utilizzando elementi di dati primitivi
- Convalidare le entità utilizzando regole specifiche del dominio
- Costruisci un modello di dominio da entità valide
- Esegui calcoli utili e interessanti con il tuo modello di dominio

Se sei in pre-alpha, il pattern Builder funzionerà perfettamente per iniziare. Probabilmente puoi saltare del tutto Builder e basta usare un'interfaccia per nascondere i tuoi setter. In ogni caso, completa le funzionalità più preziose prima di preoccuparti dei dettagli di implementazione di basso livello. Le tue funzionalità guideranno i requisiti del tuo modello di dominio.

Una volta individuati i requisiti del tuo modello di dominio, sarai in una posizione migliore per decidere se Builder è una soluzione accettabile (non necessariamente la migliore). Potresti scoprire che i campi che pensavi fossero necessari non sono affatto necessari. Ad esempio, un Pokemon deve possedere la sua resa in punti EV? Potresti invece mappare un Pokemon alla sua resa in punti EV in un modello separato? Con meno campi obbligatori, Builder può sembrare una soluzione migliore. I concetti utili qui includono la Legge di Demetra e principio di separazione delle interfacce .

Se il modello di Builder non soddisfa ancora i tuoi requisiti, prova a guardare l'associazione dei dati con Architettura Java per il binding XML (JAXB ). È uno standard che definisce come creare un'entità utilizzando i dati memorizzati come XML e include anche la convalida. Oracle ha un tutorial di base per iniziare.

Se il tuo XML ha questo aspetto:

<pokemon>
    <id>Charizard</id>
    <!-- Other elements -->
</pokemon>

Il tuo Pokemon potrebbe apparire come questo:

@XmlRootElement(name="pokemon")
public class Pokemon {

    @XmlElement(required=true)
    private String id;
}

Normalmente cerco di evitare XML, e JAXB è decisamente eccessivo per i piccoli progetti. Ma per i grandi insiemi di dati leggibili dall'uomo con regole di validazione ben definite che si integrano con Java, funziona piuttosto bene.

Un'opzione consiste nell'utilizzare un oggetto parametro .

Prendi i parametri richiesti da ogni istanza e raggruppali come una classe separata.

Vedi anche questa domanda