¿Por qué el encadenamiento de setters no es convencional?

Tener encadenado implementado en beans es muy útil: no hay necesidad de sobrecargar a los constructores, megaconstructores, fábricas y le brinda una mayor legibilidad. No puedo pensar en ningún inconveniente, a menos que desee que su objeto sea inmutable , en cuyo caso no tendría ningún setter de todos modos. Entonces, ¿hay alguna razón por la cual esta no es una convención OOP?

public class DTO {

    private String foo;
    private String bar;

    public String getFoo() {
         return foo;
    }

    public String getBar() {
        return bar;
    }

    public DTO setFoo(String foo) {
        this.foo = foo;
        return this;
    }

    public DTO setBar(String bar) {
        this.bar = bar;
        return this;
    }

}

//...//

DTO dto = new DTO().setFoo("foo").setBar("bar");

Entonces, ¿hay alguna razón por la cual no se trata de una convención OOP?

Mi mejor suposición: porque viola CQS

Tienes un comando (que cambia el estado del objeto) y una consulta (que devuelve una copia de estado, en este caso, el objeto mismo) mezclado en el mismo método. Eso no es necesariamente un problema, pero viola algunas de las pautas básicas.

Por ejemplo, en C ++, std :: stack :: pop () es un comando que devuelve void, y std :: stack :: top () es una consulta que devuelve una referencia al elemento superior en la pila. Clásicamente, te gustaría combinar los dos, pero no puedes hacer eso y estar a salvo de excepciones. (No es un problema en Java, porque el operador de asignación en Java no arroja).

Si DTO fuera un tipo de valor, podría lograr un final similar con

public DTO setFoo(String foo) {
    return new DTO(foo, this.bar);
}

public DTO setBar(String bar) {
    return new DTO(this.foo, bar);
}

Además, encadenar los valores de retorno es un dolor colosal cuando se trata de herencia. Consulte el "Patrón de plantilla curiosamente recurrente"

Finalmente, está el problema de que el constructor predeterminado debería dejarte con un objeto que esté en un estado válido. Si debe ejecutar un montón de comandos para restaurar el objeto a un estado válido, algo ha salido muy mal.

1. Guardar unas pocas teclas no es convincente. Puede ser agradable, pero las convenciones de OOP se preocupan más por conceptos y estructuras, no por pulsaciones de teclas.

2. El valor de retorno no tiene sentido.

3. Incluso más que no tener sentido, el valor de retorno es engañoso, ya que los usuarios pueden esperar que el valor de retorno tenga significado. Pueden esperar que sea un "setter inmutable"

   public FooHolder {
       public FooHolder withFoo(int foo) {
           /* return a modified COPY of this FooHolder instance */
       }
   }
   

   En realidad tu setter muta el objeto.

4. No funciona bien con la herencia.

   public FooHolder {
       public FooHolder setFoo(int foo) {
           ...
       }
   }
   

   public BarHolder extends FooHolder {
       public FooHolder setBar(int bar) {
           ...
       }
   } 
   

   puedo escribir

   new BarHolder().setBar(2).setFoo(1)

   pero no

   new BarHolder().setFoo(1).setBar(2)

Para mí, # 1 a # 3 son los más importantes. El código bien escrito no se trata de texto agradablemente organizado. El código bien escrito trata sobre los conceptos fundamentales, las relaciones y la estructura. El texto es solo un reflejo externo del verdadero significado del código.

No creo que esta sea una convención OOP, está más relacionada con el diseño del lenguaje y sus convenciones.

Parece que te gusta usar Java. Java tiene una especificación JavaBeans que especifica el tipo de retorno del setter a anular, es decir, está en conflicto con el encadenamiento de setters. Esta especificación es ampliamente aceptada e implementada en una variedad de herramientas.

Por supuesto, puede preguntar, ¿por qué no encadena parte de la especificación? No sé la respuesta, tal vez este patrón simplemente no era conocido / popular en ese momento.

Como han dicho otras personas, esto a menudo se llama una interfaz fluida .

Normalmente los establecedores son llamadas que pasan variables en respuesta al código lógico en una aplicación; Su clase DTO es un ejemplo de esto. El código convencional cuando los setters no devuelven nada es lo mejor para esto. Otras respuestas han explicado de manera.

Sin embargo, hay algunos casos en los que la interfaz fluida puede ser una buena solución, estos tienen en común.

• Las constantes se pasan principalmente a los setters
• La lógica del programa no cambia lo que se pasa a los setters.

Configuración de la configuración, por ejemplo , nhibernate fluido

Id(x => x.Id);
Map(x => x.Name)
   .Length(16)
   .Not.Nullable();
HasMany(x => x.Staff)
   .Inverse()
   .Cascade.All();
HasManyToMany(x => x.Products)
   .Cascade.All()
   .Table("StoreProduct");

Configuración de datos de prueba en pruebas unitarias, usando TestDataBulderClasses (Object Mothers) especiales

members = MemberBuilder.CreateList(4)
    .TheFirst(1).With(b => b.WithFirstName("Rob"))
    .TheNext(2).With(b => b.WithFirstName("Poya"))
    .TheNext(1).With(b => b.WithFirstName("Matt"))
    .BuildList(); // Note the "build" method sets everything else to
                  // senible default values so a test only need to define 
                  // what it care about, even if for example a member 
                  // MUST have MembershipId  set

Sin embargo, crear una buena interfaz fluida es muy difícil , por lo que solo vale la pena cuando tienes mucha configuración "estática". Además, la interfaz fluida no debe mezclarse con clases "normales"; por lo tanto, el patrón de construcción se usa a menudo.

Creo que gran parte de la razón por la que no es una convención encadenar un setter tras otro es porque para esos casos es más típico ver un objeto o parámetros de opciones en un constructor. C # también tiene una sintaxis de inicializador.

En lugar de:

DTO dto = new DTO().setFoo("foo").setBar("bar");

Se podría escribir:

(en JS)

var dto = new DTO({foo: "foo", bar: "bar"});

(Cía#)

DTO dto = new DTO{Foo = "foo", Bar = "bar"};

(en Java)

DTO dto = new DTO("foo", "bar");

setFooy setBarya no son necesarios para la inicialización, y se pueden usar para la mutación más adelante.

Si bien la capacidad de encadenamiento es útil en algunas circunstancias, es importante no intentar rellenar todo en una sola línea solo por reducir los caracteres de nueva línea.

Por ejemplo

dto.setFoo("foo").setBar("fizz").setFizz("bar").setBuzz("buzz");

hace que sea más difícil leer y comprender lo que está sucediendo. Reformateando a:

dto.setFoo("foo")
    .setBar("fizz")
    .setFizz("bar")
    .setBuzz("buzz");

Es mucho más fácil de entender y hace que el "error" en la primera versión sea más obvio. Una vez que haya refactorizado el código a ese formato, no hay una ventaja real sobre:

dto.setFoo("foo");
dto.setBar("bar");
dto.setFizz("fizz");
dto.setBuzz("buzz");

Esa técnica se usa en realidad en el patrón Builder.

x = ObjectBuilder()
        .foo(5)
        .bar(6);

Sin embargo, en general se evita porque es ambiguo. No es obvio si el valor de retorno es el objeto (por lo que puede llamar a otros establecedores), o si el objeto de retorno es el valor que se acaba de asignar (también un patrón común). En consecuencia, el Principio de Menos Sorpresa sugiere que no debe tratar de asumir que el usuario quiere ver una solución u otra, a menos que sea fundamental para el diseño del objeto.

Esto es más un comentario que una respuesta, pero no puedo comentar, así que ...

Solo quería mencionar que esta pregunta me sorprendió porque no veo esto como algo poco común . En realidad, en mi entorno de trabajo (desarrollador web) es muy muy común.

Por ejemplo, así es como la doctrina de Symfony: genera: el comando de entidades genera automáticamente todo setters , de forma predeterminada .

jQuery Kinda cadenas de la mayoría de sus métodos de una manera muy similar.