Invocación encadenada en Java 7?

Question

Estaba leyendo Java 7 preview presentation (pdf) y había una diapositiva en Invocación encadenada. Aquí está el ejemplo utilizado en la diapositiva:

// Construction with setters 
DrinkBuilder margarita = new DrinkBuilder(); 
margarita.add("tequila"); 
margarita.add("orange liqueur"); 
margarita.add("lime juice"); 
margarita.withRocks(); 
margarita.withSalt(); 
Drink drink = margarita.drink(); 

// Construction with chained invocation 
Drink margarita = new DrinkBuilder() 
    .add("tequila") 
    .add("orange liqueur") 
    .add("lime juice") 
    .withRocks() 
    .withSalt() 
    .drink(); 

Y tengo sentimientos encontrados sobre esto. Uno no debe encadenar muchas invocaciones de métodos en una sola declaración. Por otro lado, escribir margarita.this() y margarita.that() tampoco es muy conveniente.

Ahora, vengo a Java del mundo Delphi. Y en Delphi está el constructo de lenguaje with. Esto es apreciado por unos pocos y aborrecido por muchos (¿o es al revés?). Encuentro que with es más elegante que la idea de invocación encadenada (que creo que funciona sobre la base del método void que devuelve referencia al objeto sobre el que se ha invocado, y esta es la parte que no me gusta, como debería regresar voidnada).

apreciaría la característica with idioma siendo adoptado por Java, por lo que el código de ejemplo se puede escribir así:

Drink margarita = null; 
with (new DrinkBuilder()) { 
    add("tequila"); 
    add("orange liqueur"); 
    add("lime juice"); 
    withRocks(); 
    withSalt(); 
    margarita = drink(); 
} 

¿Soy el único que prefieren esta solución a la invocación encadenado? ¿Alguien más siente que with podría ser una extensión útil para el lenguaje Java? (Me recuerda a la pregunta de alguien sobre la necesidad de "Java ++" ...)

Answer 1

la con declaración se puede traducir en Java utilizando las clases anónimas con inicializador:

Drink margarita = new DrinkBuilder() {{ 
    add(“tequila”); 
    add(“orange liqueur”); 
    add(“lime juice”); 
    withRocks(); 
    withSalt(); 
}}.drink(); 

las desventajas de la utilización de este lenguaje están bien documentados here.

Invocación encadenada es un alias para Método de encadenamiento. Eso es bien conocido lenguaje y funciona con cualquier versión de Java:

class Chained { 

    public Chained withFoo() { 
     // ... 
     return this; 
    } 

    public Chained withBar() { 
     // ... 
     return this; 
    } 
}  

una propuesta de JDK 7 es allowing of chaining method also for void return type:

class ChainedJava7 { 

    public void withFoo() { 
     // ... 
    } 

    public void withBar() { 
     // ... 
    } 
}  

Answer 2

No me gusta este uso de with; Yo prefiero el Python with statement. Estoy de acuerdo con usted en que void debe significar void, sin embargo. En el ejemplo que proporcionas, si una persona realmente desea ser capaz de encadenar invocaciones de métodos, simplemente debería cambiar los tipos de devolución en sus métodos para que puedan encadenarse.

Answer 3

This te puede interesar.

Answer 4

me gusta bastante with declaraciones de esa forma, pero yo prefiero la versión VB de ellos:

With testObject 
    .Height = 100 
    .Text = "Hello, World" 
    .ForeColor = System.Drawing.Color.Green 
End With 

Como cada atributo en el bloque With todavía tiene que ser precedido por un . sabe que you'r e haciendo referencia a una propiedad Object y no, por ejemplo, a una variable local, reduciendo cualquier colisión en el espacio de nombres.

Si tomamos el ejemplo:

with (new DrinkBuilder()) { 
    add(“tequila”); 
    add(“orange liqueur”); 
    add(“lime juice”); 
    withRocks(); 
    withSalt(); 
    margarita = drink(); 
} 

no hay manera fácil de saber si withSalt() es un método de DrinkBuilder o un método en la clase local. Si solo permite los métodos del objeto with -ed en el bloque with, entonces creo que se vuelven mucho menos útiles.

Answer 5

¿Quizás las muchas llamadas a un objeto son la señal de que es necesario mover un código?

Answer 6

Joshua Bloch en Effective Java El artículo n. ° 2 recomienda encarecidamente el uso de un generador cuando tiene un constructor con muchos argumentos. Una razón es que se puede escribir para garantizar que el objeto construido esté siempre en un estado consistente. También evita tener "constructores telescópicos" complejos en la clase del objeto construido. Otra más es que si desea que el objeto construido sea inmutable (p. Ej., Para la seguridad del hilo), no puede tener métodos setter.