¿Es una mala práctica crear nuevos objetos sin almacenarlos?

He visto objetos creados en código Java sin almacenar una referencia al objeto. Por ejemplo, en un complemento de eclipse he visto un SWT Shell creado así:

new Shell();

Este nuevo objeto Shell no se almacena en una variable, pero permanecerá referenciado hasta que se elimine la ventana, lo que [creo?] Ocurre de manera predeterminada cuando se cierra la ventana.

¿Es una mala práctica crear objetos como este sin almacenar una referencia a ellos? ¿O fue la biblioteca mal diseñada? ¿Qué sucede si no necesito una referencia, pero solo quiero los "efectos secundarios" del objeto? ¿Debo guardar una referencia de todos modos?

ACTUALIZAR:

Es cierto que mi ejemplo anterior es pobre. Si bien he visto elementos de la interfaz de usuario creados de esta manera, crear un SWT Shell como este probablemente no tenga sentido porque debe llamar al método abierto en la instancia de Shell. Hay mejores ejemplos proporcionados por aix , como los siguientes del tutorial de concurrencia de Java :

(new HelloThread()).start();

Esta práctica se ve en muchos contextos, por lo que las preguntas permanecen. ¿Es una buena práctica?

Hay un elemento de preferencia personal para esto, pero creo que no almacenar la referencia no es necesariamente una mala práctica.

Considere el siguiente ejemplo hipotético:

new SingleFileProcessor().process(file);

Si es necesario crear un nuevo objeto de procesador para cada archivo, y no es necesario después de la process()llamada, no tiene sentido almacenar una referencia a él.

Aquí hay otro ejemplo, tomado del tutorial de concurrencia de Java :

(new HelloThread()).start();

He visto muchos otros ejemplos cuando la referencia no está almacenada, y eso se lee perfectamente bien para mí, como:

String str = new StringBuilder().append(x).append(y).append(z).toString();

(El StringBuilderobjeto no se guarda).

Hay patrones similares que involucran common.lang's HashCodeBuilderet al.

Si no necesita una referencia al objeto creado, no se aferre a la referencia. Es tan simple como eso.

En general, es una buena práctica publicar referencias lo más rápido posible. No veo diferencia entre:

HelloThread thread = new HelloThread();
thread.start();
// where thread is never used for the rest of the method

y

(new HelloThread()).start();

En lo que respecta al código, solo está evitando el uso de un nombre de variable, lo que podría ser algo positivo. El compilador JIT es generalmente lo suficientemente inteligente como para reconocer que puede recolectar basura el subproceso después de su último uso, por lo que probablemente no haya diferencia desde el punto de vista del rendimiento.

El único problema real que debe evitarse es el Código en el Anti-Patrón de Constructor , pero no parece que eso sea lo que está preguntando.

Esto podría ser malo si está utilizando SWT, porque allí tiene que limpiar después de usted mismo (llamando al método dispose ()). Pero para otras clases (no SWT) está bien.

Aquí hay un artículo sobre la administración de recursos del sistema operativo

En primer lugar, vas a molestar a las personas que aprendieron C o C ++ antes de Java. Lo dejaré como un ejercicio para que el lector decida si es un profesional o un estafador.

Si bien hay situaciones en las que los objetos están diseñados para ser de corta duración, la mayoría de las veces si algo es lo suficientemente complejo como para crear un objeto, es lo suficientemente complejo como para tener buenas razones para mantener una referencia, por lo que no mantenerlo en como mínimo, una advertencia para verificar dos veces si se ha perdido algo.

Por ejemplo, en un tutorial a nadie le importa mantener una referencia de subproceso, pero en la vida real, si algo demora lo suficiente como para generar un subproceso, generalmente demora lo suficiente como para poder cancelar el subproceso. O si tiene una vida más corta, generalmente está generando un montón de hilos que querrá joinantes de continuar. O desea asegurarse de que la creación de su hilo realmente haya tenido éxito. O desea asegurarse de que el hilo finalice limpiamente antes de salir. Te dan la imagen.