¿Es una mala práctica hacer que un setter devuelva "esto"?

¿Es una buena o mala idea hacer que los setters en Java devuelvan "esto"?

public Employee setName(String name){
   this.name = name;
   return this;
}

Este patrón puede ser útil porque puedes encadenar a los setters de esta manera:

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

en lugar de esto:

Employee e = new Employee();
e.setName("Jack Sparrow");
...and so on...
list.add(e);

... pero va en contra de la convención estándar. Supongo que podría valer la pena solo porque puede hacer que ese setter haga algo más útil. He visto que este patrón usa algunos lugares (por ejemplo, JMock, JPA), pero parece poco común, y solo se usa generalmente para API muy bien definidas donde este patrón se usa en todas partes.

Actualizar:

Lo que he descrito es obviamente válido, pero lo que realmente estoy buscando es algunas reflexiones sobre si esto es generalmente aceptable y si existen dificultades o prácticas recomendadas relacionadas. Sé sobre el patrón Builder, pero está un poco más involucrado que lo que estoy describiendo, como lo describe Josh Bloch, hay una clase Builder estática asociada para la creación de objetos.

No creo que haya nada específicamente malo en ello, es solo una cuestión de estilo. Es útil cuando:

• Debe configurar muchos campos a la vez (incluso en la construcción)
• sabe qué campos debe establecer en el momento en que escribe el código, y
• Hay muchas combinaciones diferentes para los campos que desea establecer.

Las alternativas a este método pueden ser:

1. Un megaconstructor (inconveniente: puede pasar muchos valores nulos o predeterminados, y es difícil saber qué valor corresponde a qué)
2. Varios constructores sobrecargados (inconveniente: se vuelve difícil de manejar una vez que tiene más de unos pocos)
3. Métodos de fábrica / estáticos (inconveniente: igual que los constructores sobrecargados; se vuelve difícil de manejar una vez que hay más de unos pocos)

Si solo va a establecer algunas propiedades a la vez, diría que no vale la pena devolver 'esto'. Ciertamente se cae si luego decide devolver algo más, como un indicador / mensaje de estado / éxito.

No es una mala práctica. Es una práctica cada vez más común. La mayoría de los idiomas no requieren que trate con el objeto devuelto si no lo desea, por lo que no cambia la sintaxis de uso del setter "normal" pero le permite encadenar los setters juntos.

Esto se llama comúnmente un patrón de construcción o una interfaz fluida .

También es común en la API de Java:

String s = new StringBuilder().append("testing ").append(1)
  .append(" 2 ").append(3).toString();

Para resumir:

• se llama "interfaz fluida" o "encadenamiento de métodos".
• esto no es Java "estándar", aunque lo ves más y más en estos días (funciona muy bien en jQuery)
• viola la especificación JavaBean, por lo que romperá con varias herramientas y bibliotecas, especialmente los constructores JSP y Spring.
• puede evitar algunas optimizaciones que la JVM normalmente haría
• algunas personas piensan que limpia el código, otras piensan que es "horrible"

Un par de otros puntos no mencionados:

• Esto viola el principio de que cada función debe hacer una (y solo una) cosa. Puede o no creer en esto, pero en Java creo que funciona bien.

• Los IDEs no los van a generar (por defecto).

• Finalmente, aquí hay un punto de datos del mundo real. He tenido problemas al usar una biblioteca construida así. El generador de consultas de Hibernate es un ejemplo de esto en una biblioteca existente. Dado que los métodos set * de Query devuelven consultas, es imposible saber con solo mirar la firma cómo usarlo. Por ejemplo:

  Query setWhatever(String what);

• Introduce una ambigüedad: el método modifica el objeto actual (su patrón) o, quizás, la consulta es realmente inmutable (un patrón muy popular y valioso), y el método está devolviendo uno nuevo. Simplemente hace que la biblioteca sea más difícil de usar, y muchos programadores no explotan esta característica. Si los setters fueran setters, sería más claro cómo usarlo.

Prefiero usar métodos 'con' para esto:

public String getFoo() { return foo; }
public void setFoo(String foo) { this.foo = foo; }
public Employee withFoo(String foo) {
  setFoo(foo);
  return this;
}

Así:

list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));

Advertencia : esta withXsintaxis se usa comúnmente para proporcionar "establecedores" para objetos inmutables, por lo que las personas que llaman de estos métodos pueden esperar razonablemente que creen nuevos objetos en lugar de mutar la instancia existente. Tal vez una redacción más razonable sería algo como:

list.add(new Employee().chainsetName("Jack Sparrow")
                       .chainsetId(1)
                       .chainsetFoo("bacon!"));

Con la convención de nombres chainsetXyz (), prácticamente todos deberían estar contentos.

Si no desea regresar 'this'del configurador pero no desea usar la segunda opción, puede usar la siguiente sintaxis para establecer las propiedades:

list.add(new Employee()
{{
    setName("Jack Sparrow");
    setId(1);
    setFoo("bacon!");
}});

Como comentario aparte, creo que es un poco más limpio en C #:

list.Add(new Employee() {
    Name = "Jack Sparrow",
    Id = 1,
    Foo = "bacon!"
});

No solo rompe la convención de getters / setters, también rompe el marco de referencia del método Java 8. MyClass::setMyValuees un BiConsumer<MyClass,MyValue>, y myInstance::setMyValuees un Consumer<MyValue>. Si le devuelve su setter this, entonces ya no es una instancia válida Consumer<MyValue>, sino una Function<MyValue,MyClass>, y causará que se rompa cualquier cosa que use referencias de métodos a esos setters (suponiendo que sean métodos nulos).

No conozco Java, pero lo hice en C ++. Otras personas han dicho que hace que las líneas sean muy largas y difíciles de leer, pero lo he hecho así muchas veces:

list.add(new Employee()
    .setName("Jack Sparrow")
    .setId(1)
    .setFoo("bacon!"));

Esto es aún mejor:

list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));

al menos eso creo. Pero puedes invitarme a votar y llamarme un programador horrible si lo deseas. Y no sé si puedes hacer esto en Java.

Este esquema (juego de palabras), llamado 'interfaz fluida', se está volviendo bastante popular ahora. Es aceptable, pero en realidad no es mi taza de té.

Como no devuelve nulo, ya no es un configurador de propiedades JavaBean válido. Eso podría importar si eres una de las siete personas en el mundo que usa herramientas visuales "Bean Builder", o una de las 17 que usan elementos JSP-bean-setProperty.

Al menos en teoría , puede dañar los mecanismos de optimización de la JVM al establecer dependencias falsas entre llamadas.

Se supone que es azúcar sintáctica, pero de hecho puede crear efectos secundarios en la máquina virtual de Java 43 súper inteligente.

Por eso voto no, no lo use.

No es una mala práctica en absoluto. Pero no es compatible con JavaBeans Spec .

Y hay muchas especificaciones que dependen de esos accesores estándar.

Siempre puedes hacer que coexistan entre sí.

public class Some {
    public String getValue() { // JavaBeans
        return value;
    }
    public void setValue(final String value) { // JavaBeans
        this.value = value;
    }
    public String value() { // simple
        return getValue();
    }
    public Some value(final String value) { // fluent/chaining
        setValue(value);
        return this;
    }
    private String value;
}

Ahora podemos usarlos juntos.

new Some().value("some").getValue();

Aquí viene otra versión para objeto inmutable.

public class Some {

    public static class Builder {

        public Some build() { return new Some(value); }

        public Builder value(final String value) {
            this.value = value;
            return this;
        }

        private String value;
    }

    private Some(final String value) {
        super();
        this.value = value;
    }

    public String getValue() { return value; }

    public String value() { return getValue();}

    private final String value;
}

Ahora podemos hacer esto.

new Some.Builder().value("value").build().getValue();

Si utiliza la misma convención en toda la aplicación, parece estar bien.

Por otro lado, si una parte existente de su aplicación usa una convención estándar, me apegaría a ella y agregaría constructores a clases más complicadas

public class NutritionalFacts {
    private final int sodium;
    private final int fat;
    private final int carbo;

    public int getSodium(){
        return sodium;
    }

    public int getfat(){
        return fat;
    }

    public int getCarbo(){
        return carbo;
    }

    public static class Builder {
        private int sodium;
        private int fat;
        private int carbo;

        public Builder sodium(int s) {
            this.sodium = s;
            return this;
        }

        public Builder fat(int f) {
            this.fat = f;
            return this;
        }

        public Builder carbo(int c) {
            this.carbo = c;
            return this;
        }

        public NutritionalFacts build() {
            return new NutritionalFacts(this);
        }
    }

    private NutritionalFacts(Builder b) {
        this.sodium = b.sodium;
        this.fat = b.fat;
        this.carbo = b.carbo;
    }
}

Paulo Abrantes ofrece otra forma de hacer que los configuradores de JavaBean sean fluidos: defina una clase de generador interno para cada JavaBean. Si está utilizando herramientas que se desconciertan por los setters que devuelven valores, el patrón de Paulo podría ayudar.

Estoy a favor de que los setters vuelvan "esto". No me importa si no es compatible con los frijoles. Para mí, si está bien tener la expresión / declaración "=", entonces los establecedores que devuelven valores están bien.

Solía ​​preferir este enfoque, pero he decidido no hacerlo.

Razones:

• Legibilidad. Hace que el código sea más legible para tener cada setFoo () en una línea separada. Por lo general, lee el código muchas, muchas veces más que la única vez que lo escribe.
• Efecto secundario: setFoo () solo debe establecer field foo, nada más. Devolver esto es un extra "QUÉ fue eso".

El patrón Builder que vi no usa la convención setFoo (foo) .setBar (bar) sino más foo (foo) .bar (bar). Quizás por exactamente esas razones.

Es, como siempre, una cuestión de gustos. Simplemente me gusta el enfoque de "menos sorpresas".

Este patrón particular se llama Método de encadenamiento. Enlace de Wikipedia , esto tiene más explicaciones y ejemplos de cómo se hace en varios lenguajes de programación.

PD: Solo pensé en dejarlo aquí, ya que estaba buscando el nombre específico.

A primera vista: "¡Horrible!".

Pensándolo mejor

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

en realidad es menos propenso a errores que

Employee anEmployee = new Employee();
anEmployee.setName("xxx");
...
list.add(anEmployee);

Muy interesante Añadiendo idea a la bolsa de herramientas ...

Sí, creo que es una buena idea.

Si pudiera agregar algo, ¿qué pasa con este problema?

class People
{
    private String name;
    public People setName(String name)
    {
        this.name = name;
        return this;
    }
}

class Friend extends People
{
    private String nickName;
    public Friend setNickName(String nickName)
    {
        this.nickName = nickName;
        return this;
    }
}

Esto funcionará:

new Friend().setNickName("Bart").setName("Barthelemy");

¡Eclipse no lo aceptará! :

new Friend().setName("Barthelemy").setNickName("Bart");

Esto se debe a que setName () devuelve un People y no un Friend, y no hay PeoplesetNickName.

¿Cómo podríamos escribir setters para devolver la clase SELF en lugar del nombre de la clase?

Algo como esto estaría bien (si existiera la palabra clave SELF). ¿Existe esto de todos modos?

class People
{
    private String name;
    public SELF setName(String name)
    {
        this.name = name;
        return this;
    }
}

En general, es una buena práctica, pero es posible que necesite que las funciones de tipo conjunto usen el tipo booleano para determinar si la operación se completó con éxito o no, esa también es una forma. En general, no hay dogma para decir que esto es bueno o la cama, proviene de la situación, por supuesto.

De la declaración

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

estoy viendo dos cosas

1) Declaración sin sentido. 2) Falta de legibilidad.

Esto puede ser menos legible

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!")); 

o esto

list.add(new Employee()
          .setName("Jack Sparrow")
          .setId(1)
          .setFoo("bacon!")); 

Esto es mucho más legible que:

Employee employee = new Employee();
employee.setName("Jack Sparrow")
employee.setId(1)
employee.setFoo("bacon!")); 
list.add(employee); 

He estado haciendo mis setters durante bastante tiempo y el único problema real es con las bibliotecas que se adhieren a los estrictos getPropertyDescriptors para obtener los accesos de bean bean reader / writer. En esos casos, su "bean" de Java no tendrá los escritores que usted esperaría.

Por ejemplo, no lo he probado con seguridad, pero no me sorprendería que Jackson no los reconozca como setters al crear objetos java a partir de json / maps. Espero estar equivocado en este caso (lo probaré pronto).

De hecho, estoy desarrollando un ORM ligero centrado en SQL y tengo que agregar algo de código entre getPropertyDescriptors a los creadores reconocidos que devuelven esto.

Hace mucho tiempo respondí, pero mis dos centavos ... Está bien. Desearía que esta interfaz fluida se usara con más frecuencia.

La repetición de la variable 'factory' no agrega más información a continuación:

ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Foo.class);
factory.setFilter(new MethodFilter() { ...

Esto es más limpio, en mi humilde opinión:

ProxyFactory factory = new ProxyFactory()
.setSuperclass(Properties.class);
.setFilter(new MethodFilter() { ...

Por supuesto, como una de las respuestas ya mencionadas, la API de Java tendría que modificarse para hacer esto correctamente en algunas situaciones, como la herencia y las herramientas.

Es mejor usar otras construcciones de lenguaje si están disponibles. Por ejemplo, en Kotlin, usaría con , aplicaría o dejaría . Si usa este enfoque, realmente no necesitará devolver una instancia de su configurador.

Este enfoque permite que su código de cliente sea:

• Indiferente al tipo de retorno
• Más fácil de mantener.
• Evitar los efectos secundarios del compilador

Aquí hay unos ejemplos.

val employee = Employee().apply {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
with(employee) {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
employee.let {
   it.name = "Jack Sparrow"
   it.id = 1
   it.foo = "bacon"
}

Si estoy escribiendo una API, uso "devolver esto" para establecer valores que solo se establecerán una vez. Si tengo otros valores que el usuario debería poder cambiar, en su lugar uso un setter vacío estándar.

Sin embargo, es realmente una cuestión de preferencia y encadenar a los setters se ve bastante bien, en mi opinión.

Estoy de acuerdo con todos los carteles que afirman que esto rompe las especificaciones de JavaBeans. Hay razones para preservar eso, pero también siento que el uso de este Patrón de Constructor (al que se aludió) tiene su lugar; siempre que no se use en todas partes, debería ser aceptable. "Es lugar", para mí, es donde el punto final es una llamada a un método "build ()".

Por supuesto, hay otras formas de establecer todas estas cosas, pero la ventaja aquí es que evita 1) constructores públicos de muchos parámetros y 2) objetos parcialmente especificados. Aquí, el constructor recopila lo que se necesita y luego llama a su "build ()" al final, lo que puede garantizar que no se construya un objeto parcialmente especificado, ya que esa operación puede tener una visibilidad inferior a la pública. La alternativa sería "objetos de parámetros", pero esa IMHO simplemente empuja el problema un nivel atrás.

No me gustan los constructores de muchos parámetros porque hacen que sea más probable que se pasen muchos argumentos del mismo tipo, lo que puede facilitar la transmisión de argumentos incorrectos a los parámetros. No me gusta usar muchos setters porque el objeto podría usarse antes de que esté completamente configurado. Además, la noción de tener valores predeterminados basados ​​en elecciones anteriores se sirve mejor con un método "build ()".

En resumen, creo que es una buena práctica, si se usa correctamente.

Mal hábito: un setter establece un getter get

¿Qué hay de declarar explícitamente un método, que lo hace para U

setPropertyFromParams(array $hashParamList) { ... }