method - java design patterns
Diseño: Java y autorreferencia regresiva en métodos setter (11)
@Dan nuevamente, para situaciones más complejas (la inmutabilidad viene en mente), el patrón de construcción es una gran solución.
Además, estoy de acuerdo contigo principalmente en getters. Creo que lo que dices es principalmente seguir el paradigma " Dime, no preguntar " y estoy muy de acuerdo. Pero eso está orientado principalmente a getters.
Por último, todo lo anterior es para las clases que tienen una gran cantidad de atributos. No veo una razón para ninguno si solo tienes menos de, digamos, 7.
Ya he propuesto esto en mi blog , pero este es el más apropiado.
Para las clases que tienen una larga lista de setters que se usan con frecuencia, encontré esta forma muy útil (aunque recientemente he leído acerca del patrón Builder en Java efectivo que es casi el mismo). Básicamente, todos los métodos setter devuelven el objeto en sí, entonces puedes usar un código como este:
MyClass
.setInt(1)
.setString("test")
.setBoolean(true)
;
Setter simplemente devuelve esto al final:
public MyClass setInt(int anInt) {
[snip]
return this;
}
¿Cuál es tu opinión? ¿Cuáles son los pros y los contras? ¿Esto tiene algún impacto en el rendimiento?
Esta idea se ve mucho en c ++, permite operaciones en cascada ...
por ejemplo
std::cout << "this" << "is" << "cascading"
es donde el método de flujo << devuelve una instancia de sí mismo (* esto).
mira esto: http://www.java2s.com/Tutorial/Cpp/0180__Class/Cascadingmemberfunctioncallswiththethispointer.htm
Esto se llama una interfaz fluida , como referencia.
Personalmente, creo que es una idea bastante clara, pero realmente una cuestión de gusto. Creo que jQuery funciona de esta manera.
Estoy de acuerdo con @Bernard en que el método de encadenamiento como este confunde el propósito de los incubadores. En su lugar, le sugiero que si siempre está creando cadenas de instaladores como este, cree un Constructor personalizado para su clase, de modo que en lugar de
MyClass
.setInt(1)
.setString("test")
.setBoolean(true)
;
Tú lo haces
new MyClass(1,"test",true);
Esto lo hace más legible y puede usarlo para hacer que su clase sea inmutable si así lo desea.
Me parece que está en mal estado cuando se usa en setters. Las clases inmutables suelen ser más adecuadas para el encadenamiento, como:
aWithB = myObject.withA(someA).withB(someB);
donde myObject es de esta clase:
class MyClass {
withA(TypeA a) {
this.a.equals(a) ? this : new MyClass(this, a);
}
private MyClass(MyClass copy, TypeA a) {
this(copy);
this.a = a;
}
}
El patrón de generador también es útil, ya que permite que el objeto final sea inmutable y, al mismo tiempo, evita las instancias intermedias que normalmente tendría que crear al usar esta técnica.
Yo no lo haría yo mismo, porque para mí es confuso lo que hace un método en particular, y el método de encadenamiento es de uso limitado para mí sobre hacerlo a mano. Sin embargo, no me va a enviar a una bola temblorosa de rabia y psicosis, que siempre es algo bueno. : '')
No me preocuparía el rendimiento; solo pregúntale a Knuth.
Yo solía ser un fan de la práctica Java (y peor C #) de hacer getters y setters (obtener propiedades de set) a través de un objeto. Este uso es lo que consideré orientado a objetos, pero realmente esto nos lleva a exponer las agallas y la implementación del objeto y no aprovechar realmente la encapsulación. Hay momentos en los que no puede salirse de esto (me viene a la mente OR / M), pero en general el objeto debe configurarse y luego realizar su función. Los objetos de mis sueños tienden a tener uno o dos constructores, y quizás media docena de funciones que sí funcionan.
La razón de esto es que una vez que comencé a desarrollar API, existe una necesidad real de mantener las cosas simples. En realidad, solo desea agregar tanta complejidad como sea necesario para realizar el trabajo, y los getters y setters, aunque simples en sí mismos, agregan complejidad en montones cuando se agregan en masa. ¿Qué sucede cuando cargo setters en un orden diferente? Anythign diferente? ¿Estás seguro?
@pek
La invocación encadenada es una de las propuestas para Java 7. Dice que si un tipo de devolución de método es nulo, debería devolverlo implícitamente. Si está interesado en este tema, hay muchos enlaces y un ejemplo simple en la página de Java 7 de Alex Miller .
Terminé haciendo esto mucho cuando trabajo con la biblioteca de Excel de POI de Apache; Terminé escribiendo métodos de ayuda que se encadenaron para poder aplicar formato, tipos de datos, datos de celda internos, fórmulas y posicionamiento de celda.
Para cosas con muchos pequeños elementos de peso mosca que necesitan pequeños retoques meticulosos, funciona bastante bien.
Tiene sentido para los constructores, donde todo lo que van a hacer es establecer un montón de cosas, crear el objeto real y tirar el constructor de distancia. Para los constructores, también podría deshacerse de la parte "establecer" del nombre del método. Del mismo modo, los tipos inmutables realmente no necesitan el "obtener".
Something thing = new SomethingBuilder()
.aProperty(wotsit)
.anotherProperty(somethingElse)
.create();
Un truco útil (si no te importa una sobrecarga de tiempo de ejecución de ~ 2K por clase) es utilizar la expresión idiomática doble:
JFrame frame = new JFrame("My frame") {{
setDefaultCloseOperation(DISPOSE_ON_CLOSE);
setLocation(frameTopLeft);
add(createContents());
pack();
setVisible(true);
}};
Cómo utilizar
/**
*
* @author sanjay
*/
public class NewClass {
private int left ;
private int top;
public void set(int x,int y)
{
left=x;
top=y;
}
public NewClass UP(int x)
{
top+=x;
return this;
}
public NewClass DOWN(int x)
{
top-=x;
return this;
}
public NewClass RIGHT(int x)
{
left+=x;
return this;
}
public NewClass LEFT(int x)
{
left-=x;
return this;
}
public void Display()
{
System.out.println("TOP:"+top);
System.out.println("/nLEFT/n:"+left);
}
}
public static void main(String[] args) {
// TODO code application logic here
NewClass test = new NewClass();
test.set(0,0);
test.Display();
test.UP(20).UP(45).DOWN(12).RIGHT(32).LEFT(20);
test.Display();