Come puoi scomporre un costruttore?

Diciamo che ho una classe Enemy, e il costruttore sarebbe simile a:

public Enemy(String name, float width, float height, Vector2 position, 
             float speed, int maxHp, int attackDamage, int defense... etc.){}

Questo sembra male perché il costruttore ha così tanti parametri, ma quando creo un'istanza Enemy ho bisogno di specificare tutte queste cose. Voglio anche questi attributi nella classe Enemy, in modo da poter scorrere un elenco di questi e ottenere / impostare questi parametri. Stavo forse pensando di sottoclasse Enemy in EnemyB, EnemyA, mentre codificavo il loro maxHp e altri attributi specifici, ma poi avrei perso l'accesso ai loro attributi hardcoded se avessi voluto iterare attraverso un elenco di Enemy (composto da EnemyA, EnemyB e EnemyC di).

Sto solo cercando di imparare a programmare in modo pulito. Se fa la differenza, lavoro in Java / C ++ / C #. Ogni punto nella giusta direzione è apprezzato.

La soluzione è raggruppare i parametri in tipi compositi. Larghezza e altezza sono concettualmente correlate: specificano le dimensioni del nemico e di solito saranno necessarie insieme. Potrebbero essere sostituiti con un Dimensionstipo, o forse un Rectangletipo che include anche la posizione. D'altra parte, potrebbe essere più sensato raggruppare positione speedinserire un MovementDatatipo, specialmente se l'accelerazione entra in un secondo momento. Dal contesto Presumo maxHp, attackDamage, defense, ecc appartengono anche insieme in un Statstipo. Quindi, una firma rivista potrebbe essere simile a questa:

public Enemy(String name, Dimensions dimensions, MovementData movementData, Stats stats)

I dettagli precisi su dove tracciare le linee dipenderanno dal resto del codice e da quali dati vengono comunemente utilizzati insieme.

Potresti dare un'occhiata al modello Builder . Dal collegamento (con un esempio del modello rispetto alle alternative):

[Il] modello Builder è una buona scelta quando si progettano classi i cui costruttori o fabbriche statiche avrebbero più di una manciata di parametri, specialmente se la maggior parte di questi parametri sono opzionali. Il codice client è molto più facile da leggere e scrivere con i costruttori che con il tradizionale modello di costruzione telescopica, e i costruttori sono molto più sicuri di JavaBeans.

L'uso di sottoclassi per preimpostare alcuni valori non è auspicabile. Sottoclasse solo quando un nuovo tipo di nemico ha un comportamento diverso o nuovi attributi.

Il modello di fabbrica viene solitamente utilizzato per astrarre sull'esatta classe utilizzata, ma può anche essere utilizzato per fornire modelli per la creazione di oggetti:

class EnemyFactory {

    // each of these methods is essentially a template for a kind of enemy

    Enemy enemyA(String name, ...) {
        return new Enemy(name, ..., presetValue, ...);
    }

    Enemy enemyB(String name, ...) {
        return new Enemy(name, ..., otherValue, ...);
    }

    Enemy enemyC(String name, ...) {
        return new EnemySubclass(name, ..., otherValue, ...);
    }

    ...
}

EnemyFactory factory = new EnemyFactory();
Enemy a = factory.enemyA("fred", ...);
Enemy b = factory.enemyB("willy", ...);

Riserverei la sottoclasse alle classi che rappresentano oggetti che potresti voler usare indipendentemente, ad esempio la classe di caratteri in cui tutti i personaggi, non solo i nemici hanno nome, velocità, maxHp o una classe per rappresentare gli sprite che hanno una presenza sullo schermo con larghezza, altezza, posizione.

Non vedo nulla di intrinsecamente sbagliato in un costruttore con molti parametri di input ma se vuoi dividerlo un po 'potresti avere un costruttore che imposta la maggior parte dei parametri e un altro costruttore (sovraccarico) che può essere usato per impostare quelli specifici e impostarne altri sui valori predefiniti.

A seconda della lingua che scegli di utilizzare, alcuni possono impostare valori predefiniti per i parametri di input del costruttore come:

Enemy(float height = 42, float width = 42);

Un esempio di codice da aggiungere alla risposta di Rory Hunter (in Java):

public class Enemy{
   private String name;
   private float width;
   ...

   public static class Builder{
       private Enemy instance;

       public Builder(){
           this.instance = new Enemy();
       }


       public Builder withName(String name){
           instance.name = name;
           return this;
       }

       ...

       public Enemy build(){
           return instance;
       }
   }
}

Ora puoi creare nuove istanze di Enemy in questo modo:

Enemy myEnemy = new Enemy.Builder().withName("John").withX(x).build();