¿Cómo puedes descomponer un constructor?

Digamos que tengo una clase de Enemigo, y el constructor se vería así:

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

Esto se ve mal porque el constructor tiene muchos parámetros, pero cuando creo una instancia de Enemy necesito especificar todas estas cosas. También quiero estos atributos en la clase Enemy, para poder iterar a través de una lista de ellos y obtener / establecer estos parámetros. Estaba pensando en subclasificar Enemy en EnemyB, EnemyA, mientras codificaba su maxHp y otros atributos específicos, pero luego perdería el acceso a sus atributos codificados si quisiera recorrer una lista de Enemy (que consta de EnemyA, EnemyB y EnemyC's).

Solo estoy tratando de aprender a codificar limpiamente. Si hace la diferencia, trabajo en Java / C ++ / C #. Cualquier punto en la dirección correcta es apreciado.

La solución es agrupar los parámetros en tipos compuestos. El ancho y la altura están relacionados conceptualmente: especifican las dimensiones del enemigo y generalmente se necesitarán juntos. Podrían reemplazarse con un Dimensionstipo, o tal vez un Rectangletipo que también incluya la posición. Por otro lado, podría tener más sentido agrupar positiony speedformar un MovementDatatipo, especialmente si la aceleración luego entra en escena. A partir del contexto Asumo maxHp, attackDamage, defense,, etc también pertenecen juntos en un Statstipo. Entonces, una firma revisada podría verse así:

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

Los detalles finos de dónde dibujar las líneas dependerán del resto de su código y qué datos se usan comúnmente juntos.

Es posible que desee echar un vistazo al patrón Builder . Desde el enlace (con ejemplos del patrón versus las alternativas):

[El] patrón de constructor es una buena opción cuando se diseñan clases cuyos constructores o fábricas estáticas tendrían más de un puñado de parámetros, especialmente si la mayoría de esos parámetros son opcionales. El código del cliente es mucho más fácil de leer y escribir con los constructores que con el patrón de constructor telescópico tradicional, y los constructores son mucho más seguros que JavaBeans.

Usar subclases para preestablecer algunos valores no es deseable. Solo subclase cuando un nuevo tipo de enemigo tiene un comportamiento diferente o nuevos atributos.

El patrón de fábrica generalmente se usa para abstraer sobre la clase exacta utilizada, pero también se puede usar para proporcionar plantillas para la creación de objetos:

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", ...);

Me gustaría reservar subclases para las clases que representan objetos que tal vez quieras usar de forma independiente, por ejemplo, la clase de personaje donde todos los personajes, no solo los enemigos, tienen nombre, velocidad, maxHp o una clase para representar sprites que tienen presencia en pantalla con ancho, altura, posición.

No veo nada inherentemente incorrecto con un constructor con muchos parámetros de entrada, pero si desea dividirlo un poco, entonces podría tener un constructor que configure la mayoría de los parámetros y otro constructor (sobrecargado) que pueda usarse para establecer valores específicos y hacer que otros establezcan valores predeterminados.

Dependiendo del idioma que elija usar, algunos pueden establecer valores predeterminados para los parámetros de entrada de su constructor como:

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

Un ejemplo de código para agregar a la respuesta de Rory Hunter (en 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;
       }
   }
}

Ahora, puedes crear nuevas instancias de Enemy como esta:

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