He visto muchas implementaciones del patrón Builder (principalmente en Java). Todos ellos tienen una clase de entidad (digamos una Personclase) y una clase de generador PersonBuilder. El constructor "apila" una variedad de campos y devuelve un new Personcon los argumentos pasados. ¿Por qué necesitamos explícitamente una clase de generador, en lugar de poner todos los métodos de generador en la Personclase misma?

Por ejemplo:

class Person {

  private String name;
  private Integer age;

  public Person() {
  }

  Person withName(String name) {
    this.name = name;
    return this;
  }

  Person withAge(int age) {
    this.age = age;
    return this;
  }
}

Simplemente puedo decir Person john = new Person().withName("John");

¿Por qué la necesidad de una PersonBuilderclase?

El único beneficio que veo es que podemos declarar los Personcampos como final, asegurando así la inmutabilidad.

Es para que pueda ser inmutable Y simular parámetros con nombre al mismo tiempo.

Person p = personBuilder
    .name("Arthur Dent")
    .age(42)
    .build()
;

Eso mantiene a tus guantes alejados de la persona hasta que se establece su estado y, una vez configurado, no te permite cambiarlo, sin embargo, cada campo está claramente etiquetado. No puede hacer esto con solo una clase en Java.

Parece que estás hablando de Josh Blochs Builder Pattern . Esto no debe confundirse con el Patrón de Constructor de la Banda de los Cuatro . Estas son diferentes bestias. Ambos resuelven problemas de construcción, pero de maneras bastante diferentes.

Por supuesto, puedes construir tu objeto sin usar otra clase. Pero luego tienes que elegir. Pierde la capacidad de simular parámetros con nombre en lenguajes que no los tienen (como Java) o pierde la capacidad de permanecer inmutable durante toda la vida útil de los objetos.

Ejemplo inmutable, no tiene nombres para parámetros

Person p = new Person("Arthur Dent", 42);

Aquí estás construyendo todo con un solo constructor simple. Esto le permitirá permanecer inmutable, pero perderá la simulación de parámetros con nombre. Eso se vuelve difícil de leer con muchos parámetros. A las computadoras no les importa, pero es difícil para los humanos.

Ejemplo de parámetro con nombre simulado con setters tradicionales. No inmutable

Person p = new Person();
p.name("Arthur Dent");
p.age(42);

Aquí está creando todo con setters y simulando parámetros con nombre, pero ya no es inmutable. Cada uso de un setter cambia el estado del objeto.

Entonces, lo que obtienes al agregar la clase es que puedes hacer ambas cosas.

La validación se puede realizar build()si un error de tiempo de ejecución para un campo de edad faltante es suficiente para usted. Puede actualizar eso y aplicar eso que age()se llama con un error del compilador. Simplemente no con el patrón de construcción Josh Bloch.

Para eso necesita un lenguaje interno específico de dominio (iDSL).

Esto le permite exigir que llamen age()y name()antes de llamar build(). Pero no puede hacerlo simplemente volviendo thiscada vez. Cada cosa que regresa devuelve una cosa diferente que te obliga a llamar a la siguiente.

El uso podría verse así:

Person p = personBuilder
    .name("Arthur Dent")
    .age(42)
    .build()
;

Pero esto:

Person p = personBuilder
    .age(42)
    .build()
;

provoca un error del compilador porque age()solo es válido llamar al tipo devuelto por name().

Estos iDSL son extremadamente potentes ( JOOQ o Java8 Streams, por ejemplo) y son muy agradables de usar, especialmente si usa un IDE con finalización de código, pero su configuración es bastante complicada . Recomiendo guardarlos para cosas que tengan un poco de código fuente escrito en su contra.

Por qué usar / proporcionar una clase de constructor:

• Para hacer objetos inmutables: el beneficio que ya ha identificado. Útil si la construcción toma varios pasos. FWIW, la inmutabilidad debería verse como una herramienta importante en nuestra búsqueda para escribir programas mantenibles y libres de errores.
• Si la representación en tiempo de ejecución del objeto final (posiblemente inmutable) está optimizada para lectura y / o uso de espacio, pero no para actualización. String y StringBuilder son buenos ejemplos aquí. Concatenar cadenas repetidamente no es muy eficiente, por lo que StringBuilder utiliza una representación interna diferente que es buena para agregar, pero no tan buena en el uso del espacio, y no tan buena para leer y usar como la clase de cadena regular.
• Para separar claramente los objetos construidos de los objetos en construcción. Este enfoque requiere una transición clara de la subconstrucción a la construcción. Para el consumidor, no hay forma de confundir un objeto en construcción con un objeto construido: el sistema de tipos hará cumplir esto. Eso significa que a veces podemos usar este enfoque para "caer en el pozo del éxito", por así decirlo, y, al hacer abstracción para que otros (o nosotros mismos) lo usemos (como una API o una capa), esto puede ser muy bueno cosa.

Una razón sería asegurar que todos los datos pasados ​​sigan las reglas de negocio.

Su ejemplo no toma esto en consideración, pero digamos que alguien pasó una cadena vacía o una cadena que consiste en caracteres especiales. Desea hacer algún tipo de lógica basada en asegurarse de que su nombre sea realmente un nombre válido (que en realidad es una tarea muy difícil).

Podría poner todo eso en su clase de Persona, especialmente si la lógica es muy pequeña (por ejemplo, solo asegurándose de que una edad no sea negativa), pero a medida que la lógica crece, tiene sentido separarla.

Un pequeño ángulo diferente sobre esto de lo que veo en otras respuestas.

El withFooenfoque aquí es problemático porque se comportan como setters pero se definen de una manera que hace que parezca que la clase admite la inmutabilidad. En las clases de Java, si un método modifica una propiedad, es costumbre comenzar el método con 'set'. Nunca me ha encantado como estándar, pero si haces algo más, sorprenderá a la gente y eso no es bueno. Hay otra forma en que puede admitir la inmutabilidad con la API básica que tiene aquí. Por ejemplo:

class Person {
  private final String name;
  private final Integer age;

  private Person(String name, String age) {
    this.name = name;
    this.age = age;
  }  

  public Person() {
    this.name = null;
    this.age = null;
  }

  Person withName(String name) {
    return new Person(name, this.age);
  }

  Person withAge(int age) {
    return new Person(this.name, age);
  }
}

No proporciona mucho en cuanto a la prevención de objetos construidos parcialmente de manera inadecuada, pero evita cambios en cualquier objeto existente. Probablemente sea una tontería para este tipo de cosas (y también lo es el JB Builder). Sí, creará más objetos, pero esto no es tan costoso como podría pensar.

En su mayoría, verá este tipo de enfoque utilizado con estructuras de datos concurrentes, como CopyOnWriteArrayList . Y esto sugiere por qué la inmutabilidad es importante. Si desea que su código sea seguro, casi siempre debe considerarse la inmutabilidad. En Java, cada subproceso puede mantener un caché local de estado variable. Para que un subproceso vea los cambios realizados en otros subprocesos, debe emplearse un bloque sincronizado u otra característica de concurrencia. Cualquiera de estos agregará algo de sobrecarga al código. Pero si sus variables son finales, no hay nada que hacer. El valor siempre será el que se inicializó y, por lo tanto, todos los subprocesos ven lo mismo sin importar qué.

Otra razón que aún no se ha mencionado explícitamente aquí, es que el build()método puede verificar que todos los campos son 'campos que contienen valores válidos (ya sea establecidos directamente o derivados de otros valores de otros campos), que probablemente sea el modo de falla más probable eso ocurriría de otra manera.

Otro beneficio es que su Personobjeto terminaría teniendo una vida más simple y un conjunto simple de invariante. Sabes que una vez que tienes un Person p, tienes un p.namey un válido p.age. Ninguno de sus métodos tiene que estar diseñado para manejar situaciones como "bueno, ¿qué pasa si se establece la edad pero no el nombre, o qué pasa si se establece el nombre pero no la edad? Esto reduce la complejidad general de la clase.

También se puede definir un generador para devolver una interfaz o una clase abstracta. Puede usar el constructor para definir el objeto, y el constructor puede determinar qué subclase concreta devolver en función de qué propiedades están establecidas o en qué están configuradas, por ejemplo.

El patrón de construcción se usa para construir / crear el objeto paso a paso configurando las propiedades y cuando se configuran todos los campos requeridos, devuelve el objeto final utilizando el método de construcción. El objeto recién creado es inmutable. El punto principal a tener en cuenta aquí es que el objeto solo se devuelve cuando se invoca el método de compilación final. Esto asegura que todas las propiedades se establecen en el objeto y, por lo tanto, el objeto no está en estado inconsistente cuando la clase de constructor lo devuelve.

Si no usamos la clase de constructor y colocamos directamente todos los métodos de la clase de constructor en la clase Persona en sí, primero tenemos que crear el Objeto y luego invocar los métodos de establecimiento en el objeto creado, lo que conducirá al estado inconsistente del objeto entre la creación. de objeto y establecer las propiedades.

Por lo tanto, al usar la clase de constructor (es decir, alguna entidad externa que no sea la clase Person), nos aseguramos de que el objeto nunca estará en un estado inconsistente.

Reutilizar objeto constructor

Como otros han mencionado, la inmutabilidad y la verificación de la lógica empresarial de todos los campos para validar el objeto son las principales razones para un objeto generador separado.

Sin embargo, la reutilización es otro beneficio. Si quiero crear una instancia de muchos objetos que son muy similares, puedo hacer pequeños cambios en el objeto generador y continuar creando instancias. No es necesario volver a crear el objeto generador. Esta reutilización permite al constructor actuar como plantilla para crear muchos objetos inmutables. Es un pequeño beneficio, pero podría ser útil.

En realidad, puede tener los métodos de construcción en su propia clase y aún así tener inmutabilidad. Simplemente significa que los métodos del generador devolverán nuevos objetos, en lugar de modificar el existente.

Esto solo funciona si hay una manera de obtener un objeto inicial (válido / útil) (por ejemplo, de un constructor que establece todos los campos requeridos, o un método de fábrica que establece los valores predeterminados), y los métodos de construcción adicionales devuelven objetos modificados basados en el existente. Esos métodos de creación deben asegurarse de no obtener objetos inválidos / inconsistentes en el camino.

Por supuesto, esto significa que tendrá muchos objetos nuevos, y no debe hacerlo si sus objetos son caros de crear.

Lo utilicé en el código de prueba para crear emparejadores de Hamcrest para uno de mis objetos comerciales. No recuerdo el código exacto, pero se parecía a esto (simplificado):

public class CustomerMatcher extends TypeSafeMatcher<Customer> {
    private final Matcher<? super String> nameMatcher;
    private final Matcher<? super LocalDate> birthdayMatcher;

    @Override
    protected boolean matchesSafely(Customer c) {
        return nameMatcher.matches(c.getName()) &&
               birthdayMatcher.matches(c.getBirthday());
    }

    private CustomerMatcher(Matcher<? super String> nameMatcher,
                            Matcher<? super LocalDate> birthdayMatcher) {
        this.nameMatcher = nameMatcher;
        this.birthdayMatcher = birthdayMatcher;
    }

    // builder methods from here on

    public static CustomerMatcher isCustomer() {
        // I could return a static instance here instead
        return new CustomerMatcher(Matchers.anything(), Matchers.anything());
    }

    public CustomerMatcher withBirthday(Matcher<? super LocalDate> birthdayMatcher) {
        return new CustomerMatcher(this.nameMatcher, birthdayMatcher);
    }

    public CustomerMatcher withName(Matcher<? super String> nameMatcher) {
        return new CustomerMatcher(nameMatcher, this.birthdayMatcher);
    }
}

Luego lo usaría así en mis pruebas unitarias (con importaciones estáticas adecuadas):

assertThat(result, is(customer().withName(startsWith("Paŭlo"))));