Cual es mejor utilizar patron singleton o static?
462 views
Skip to first unread message
Gustavo Antonio Correa Caja
Jan 26, 2012, 7:29:04 PM1/26/12
to jav...@googlegroups.com
Cual es mejor(optimizacion,etc) a utilizar en una clase Util?
Por ejemplo :
Caso 1:
public class Util {
public Util() {}
public static Object metodosX(){
return null;
}
}
Caso 2:
public class Util {
public Util() {}
private static class UtilHolder {
public static final Util instance = new Util();
}
public static Util getInstance() {
return UtilHolder.instance;
}
public Object metodosX(){
return null;
}
}
Espero que me hallan entendido mi duda.
--
Gustavo Antonio Correa Caja
Por ejemplo :
Caso 1:
public class Util {
public Util() {}
public static Object metodosX(){
return null;
}
}
Caso 2:
public class Util {
public Util() {}
private static class UtilHolder {
public static final Util instance = new Util();
}
public static Util getInstance() {
return UtilHolder.instance;
}
public Object metodosX(){
return null;
}
}
Espero que me hallan entendido mi duda.
--
Gustavo Antonio Correa Caja
pablo.a....@gmail.com
Jan 26, 2012, 8:29:36 PM1/26/12
to jav...@googlegroups.com
Si son solo métodos utilitarios y no hay que guardar estado, metodos estáticos son mejores.
Saludos
--
www.JavaSOS.com
Grupo de colaboración Java/J2ee para desarrolladores de habla hispana.
Nick Risaro
Jan 26, 2012, 8:34:28 PM1/26/12
to jav...@googlegroups.com
No por nada Singleton es la S de STUPID http://nikic.github.com/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html
Como dice Pablo, si no hay ningún estado que almacenar static va a ser más rápido, sino fijate en las clases utilitarias que vienen en el JDK como Math por ejemplo.
Saludos
Como dice Pablo, si no hay ningún estado que almacenar static va a ser más rápido, sino fijate en las clases utilitarias que vienen en el JDK como Math por ejemplo.
Saludos
2012/1/26 pablo.a....@gmail.com <pablo.a....@gmail.com>
Gustavo Antonio Correa Caja
Jan 26, 2012, 9:54:18 PM1/26/12
to jav...@googlegroups.com
K chevre!
No hay nadie que este en contra de los que ellos dicen.
Creo que falta mas sustento.
No hay nadie que este en contra de los que ellos dicen.
Creo que falta mas sustento.
Nick Risaro
Jan 26, 2012, 10:55:32 PM1/26/12
to jav...@googlegroups.com
Más sustento a la opción de static?
El footprint de memoria es menor.
El código es más legible.
El compilador puede hacer inlining (perdón por el neologismo) para mejorar la performance.
Si tu clase solo va a tener métodos utilitarios hacer un singleton va en contra del "espíritu" del patrón.
Espero la réplica de los singleton-fans :p
Pablo Lillia
Jan 27, 2012, 4:24:53 PM1/27/12
to jav...@googlegroups.com
El 27/01/12 00:55, Nick Risaro escribi�:
>
> M�s sustento a la opci�n de static?
>
> El footprint de memoria es menor.
> El c�digo es m�s legible.
> El compilador puede hacer inlining (perd�n por el neologismo) para
> mejorar la performance.
> Si tu clase solo va a tener m�todos utilitarios hacer un singleton va
> en contra del "esp�ritu" del patr�n.
>
> Espero la r�plica de los singleton-fans :p
>
>
+1, coincido plenamente. Pueden anotarme en la lista de los
singleton-haters :)
>
> M�s sustento a la opci�n de static?
>
> El footprint de memoria es menor.
> El compilador puede hacer inlining (perd�n por el neologismo) para
> mejorar la performance.
> Si tu clase solo va a tener m�todos utilitarios hacer un singleton va
> en contra del "esp�ritu" del patr�n.
>
> Espero la r�plica de los singleton-fans :p
>
>
+1, coincido plenamente. Pueden anotarme en la lista de los
singleton-haters :)
Una clase utilitaria, por definici�n, no tiene nada que ver con el
patr�n Singleton. El patr�n Singleton es una soluci�n para asegurarse
que exista una instancia �nica de una clase y una clase utilitaria NO
tiene instancias! En la utilitaria los m�todos son est�ticos, no hay
estado, no hay instancia[2].
Si hay alguna similitud, es que ambos, Singleton y Utilitaria deber�an
tener constructores privados. En la Utilitaria con el objetivo de
anularlo. En el Singleton, para que sea usado exclusivamente por el
m�todo instance() que la devuelve (si se hace instalaci�n lazy, como
suele hacerse) o usada en la inicializaci�n est�tica (para hacer
inicializaci�n eager).
Es importante conocer el patr�n Singleton... para NO usarlo. Aunque est�
documentado, hay mejores soluciones siempre (como toda regla puede
romperse muuuuy excepcionalmente). Ver [1]
Sin ir m�s lejos, Singleton complica las pruebas unitarias, lleva a
abusarse de �l, y es una forma de estado global sucia (a.k.a. variable
global). Tiene m�s problemas que ventajas y est� desaconsejado. Como es
el patr�n m�s simple, suele abusarse de �l (�mira mam�, uso
patrones!!!). Normalmente tenemos alg�n framework de IoC (sea cual sea
el tipo de aplicaci�n y tecnolog�a), que se encargar� de manejar beans
singletons de forma m�s elegante, dentro de un contexto apropiado.
Slds.-
Pablo
[1] http://en.wikipedia.org/wiki/Singleton_pattern
[2] http://en.wikipedia.org/wiki/Utility_pattern
Leandro Spadaro
Jan 30, 2012, 6:45:41 AM1/30/12
to (Grupo Java Google) Lista
Opino igual Pablo,
Y como en toda situación como esta la que planteas se debe tratar de ver cual de las opciones es la mejor,
Lei la el articulo que enviaron http://nikic.github.com/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html
Tiene algunas cosas que se pueden rescatar, pero si fueran tan de esa forma como lo plantean me llama muchisimo la atención que
concenptualmente se utiliza para Spring, Hibernate y en la especificacionde EJB 3.1 hasta se creo una anotación @Singleston.
Por eso mismo opino muy similar a lo que dice Pablo, creo que una cosa es el concepto de instancia única que se quiere trasmitir con el
patrón, y otra cosa es su implementación. La cual si bien los patrones se suponene que son soluciones probadas vi muchas formas distintas
de implementar el patrón.
saludos.
Leo.
Y como en toda situación como esta la que planteas se debe tratar de ver cual de las opciones es la mejor,
Lei la el articulo que enviaron http://nikic.github.com/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html
Tiene algunas cosas que se pueden rescatar, pero si fueran tan de esa forma como lo plantean me llama muchisimo la atención que
concenptualmente se utiliza para Spring, Hibernate y en la especificacionde EJB 3.1 hasta se creo una anotación @Singleston.
Por eso mismo opino muy similar a lo que dice Pablo, creo que una cosa es el concepto de instancia única que se quiere trasmitir con el
patrón, y otra cosa es su implementación. La cual si bien los patrones se suponene que son soluciones probadas vi muchas formas distintas
de implementar el patrón.
saludos.
Leo.
> Date: Fri, 27 Jan 2012 18:24:53 -0300
> From: pablo....@gmail.com
> To: jav...@googlegroups.com
> Subject: Re: [JavaSOS] Cual es mejor utilizar patron singleton o static?
>
> El 27/01/12 00:55, Nick Risaro escribió:
> >
> > Más sustento a la opción de static?
> From: pablo....@gmail.com
> To: jav...@googlegroups.com
> Subject: Re: [JavaSOS] Cual es mejor utilizar patron singleton o static?
>
> El 27/01/12 00:55, Nick Risaro escribió:
> >
> > Más sustento a la opción de static?
> >
> > El footprint de memoria es menor.
> > El código es más legible.
> > El compilador puede hacer inlining (perdón por el neologismo) para
> > mejorar la performance.
> > El compilador puede hacer inlining (perdón por el neologismo) para
> > mejorar la performance.
> > Si tu clase solo va a tener métodos utilitarios hacer un singleton va
> > en contra del "espíritu" del patrón.
> >
> > Espero la réplica de los singleton-fans :p
> >
> >
> +1, coincido plenamente. Pueden anotarme en la lista de los
> singleton-haters :)
>
> Una clase utilitaria, por definición, no tiene nada que ver con el
> patrón Singleton. El patrón Singleton es una solución para asegurarse
> que exista una instancia única de una clase y una clase utilitaria NO
> tiene instancias! En la utilitaria los métodos son estáticos, no hay
> patrón Singleton. El patrón Singleton es una solución para asegurarse
> que exista una instancia única de una clase y una clase utilitaria NO
> tiene instancias! En la utilitaria los métodos son estáticos, no hay
> estado, no hay instancia[2].
>
>
> Si hay alguna similitud, es que ambos, Singleton y Utilitaria deberían
> tener constructores privados. En la Utilitaria con el objetivo de
> anularlo. En el Singleton, para que sea usado exclusivamente por el
> anularlo. En el Singleton, para que sea usado exclusivamente por el
> método instance() que la devuelve (si se hace instalación lazy, como
> suele hacerse) o usada en la inicialización estática (para hacer
> inicialización eager).
>
> Es importante conocer el patrón Singleton... para NO usarlo. Aunque está
> suele hacerse) o usada en la inicialización estática (para hacer
> inicialización eager).
>
> Es importante conocer el patrón Singleton... para NO usarlo. Aunque está
> documentado, hay mejores soluciones siempre (como toda regla puede
> romperse muuuuy excepcionalmente). Ver [1]
>
> romperse muuuuy excepcionalmente). Ver [1]
>
> Sin ir más lejos, Singleton complica las pruebas unitarias, lleva a
> abusarse de él, y es una forma de estado global sucia (a.k.a. variable
> global). Tiene más problemas que ventajas y está desaconsejado. Como es
> el patrón más simple, suele abusarse de él (¡mira mamá, uso
> patrones!!!). Normalmente tenemos algún framework de IoC (sea cual sea
> el tipo de aplicación y tecnología), que se encargará de manejar beans
> singletons de forma más elegante, dentro de un contexto apropiado.
> abusarse de él, y es una forma de estado global sucia (a.k.a. variable
> global). Tiene más problemas que ventajas y está desaconsejado. Como es
> el patrón más simple, suele abusarse de él (¡mira mamá, uso
> patrones!!!). Normalmente tenemos algún framework de IoC (sea cual sea
> el tipo de aplicación y tecnología), que se encargará de manejar beans
> singletons de forma más elegante, dentro de un contexto apropiado.
>
> Slds.-
> Pablo
>
> [1] http://en.wikipedia.org/wiki/Singleton_pattern
> [2] http://en.wikipedia.org/wiki/Utility_pattern
>
Pablo Codeiro
Jan 30, 2012, 9:09:32 AM1/30/12
to jav...@googlegroups.com
La diferencia es que vos al utilizar Spring te abstraes de la idea de si es o no es un singleton.
Simplemente lo seteas en la metadata y listo. Cuando vos consumis la instancia, no tenes idea si es una unica instancia o no.
El caso de ejemplo que da STUPID, es si primero tenes una conexion a una base de datos, y luego, tenes que utilizar dos bases de datos envez de una.
De forma "comun" (sin algo como Spring), si hiciste un Singleton, tenes que cambiarlo por un Multiton, con todos los cambios que ello implica.
Teniendo Spring, no es mas que cambiar los metadatos (el context) en donde le vas a especificar que conexión le vas a inyectar a que bean.... Cuando programes, vas a seguir programando igual que siempre, practicamente sin ningun impacto en tu codigo fuente...
La idea, repito, es que te olvides si el objeto es un singleton, un multiton, o cualquier cosa. Y eso en realidad es lo que se critica, lo que lo vuelve feo, e "inmantenible"... no el concepto de singleton por si mismo...
En otros lenguajes (como python, por ej), al poder modificar como funciona el constructor, este problema no pasa.
def singleton(cls):
instances = {}
def getinstance():
if cls not in instances:
instances[cls] = cls()
return instances[cls]
return getinstance
@singleton
class MyClass:
Fijate que acá, "MyClass" le decis que vas a usar un singleton mediante metadatos (se llaman "decoradores", es como una annotatio pero mas copada). Despues, cuando vos uses MyClass, la vas a usar de la misma forma que usas otro objeto, sea o no sea un singleton. Le haces new, y lo utilizas. Python tiene como caracteristica que podes "sobreescribir" la funcionalidad del constructor, pudiendo decirle al interprete "envez de crear un objeto nuevo, devolvé este otro que ya está creado".
Si el dia de mañana, el singleton se tiene que transformar en una suerte de multiton, solamente vas a cambiar el constructor de la clase, y NO tooodas las veces que instancias ese objetos singleton (como si pasaría en java).
Creo que he sido un poco confuso con mi explicación.... cualquier cosa preguntá :P
Pablo Codeiro
Jan 30, 2012, 9:15:02 AM1/30/12
to jav...@googlegroups.com
Perdon, el codigo de python que queria escribir es este, pero copy-pastie mal:
class Singleton(object):
_instance = None
def __new__(cls, *args, **kwargs):
if not cls._instance:
cls._instance = super(Singleton, cls).__new__(
cls, *args, **kwargs)
return cls._instance
aca lo que hace es sobreescribir el constructor, para retornarle la instancia compartida por todos. Cuando queres crear una instancia, la creas de forma normal ( new MiClase() en java sería). Si el dia de mañana no queres que sea singleton, simplemente borras el __new__ y listo... todo lo demas en todas las clases permanecen igual, mejorando la mantenibilidad del código... Cosa que perdes al utilizar statics en java.
Leandro Spadaro
Jan 30, 2012, 9:44:24 AM1/30/12
to (Grupo Java Google) Lista
Estamos totalmente de acuerdo, insisto con lo mismo, sea como lo hace Spring o como lo hagan otros es como se implementa el problema
si es de forma eficienta en algunos casos y quizas no tan eficientes en otros.
Pero el concepto que trasmite el patrón es que exista una única instancia para toda la aplicación.
En EJB 3.1 con la anotacion @Singleston la idea es que uno conoce el concepto del patrón y sabes lo que significa, pero nadie sabe
como lo implemeta el servidor de aplicaciones, lo que si sabes es que simpre vas a tener una única instancia de la clase.
Es más estoy seguro que GlassFishh lo hace de una manera y JBOSS lo hace de otra por ejemplo.
Por eso digo que el artículo tiene cosas que se rescantan dentro del contexto que lo explica (uno se puede equivocar y debe estar bien probado),
pero que el concepto se aplica en las librerias, estandares y framework más conocidos. Tal es asi, que uno puede buscar dentro de hibernate y
encontrar clases tal cual el patrón se encuentra documnetado. El tema esta en como el resto del hibernate administra de forma eficiento o no, esos singleston.
Como comentas muy bien vos, en Spring te abstraes de si es o no un Singleston, pero vos tenes idea si esos singleston o no de los cuales
te abstraes estan bien o mal administrado, seguramente me diras Spring es un producto muy probado y seguramente muy testeado que
hace que todo funciones bien. A lo que apunto es que te abstraigas no sinifican que no estan.
Por eso decia que estaba de acuerdo con Pablo que uno lo debe conocer y conocer otras alternativas, para saber cuando implementarlo de forma correcta
para que te aporte algo a tú desarrollo.
Y vuelvo con lo mismo a no te llama la atención que si bien es un patrón que se recomienda tener cuidado con su uso, muchos de los productos más conocido
lo implemnetan de una forma u otra, evidentemtente no todo es malo con el patrón.
Por ejemplo a mi me llama la atención que la especificacion de EJB 3.1 donde participan empresas muy reconocidas, decidieran agregar la anotación @Singleston
(lo que no significa que sea lo mejor muchas de esas empresas armaron la especificacion de EJB 2.1 y la verdad que no les fue muy bien). A lo que voy es que el
patrón tarde o temprano lo terminana usando por lo menos conceptualmente independientemente de como se implementa.
Si bien nos fuimos de tema con respecto al tema original, no estoy diciendo que static sea malo ojo, solo creo que se debe evaluar la mejor opción.
saludos.
Leo.
si es de forma eficienta en algunos casos y quizas no tan eficientes en otros.
Pero el concepto que trasmite el patrón es que exista una única instancia para toda la aplicación.
En EJB 3.1 con la anotacion @Singleston la idea es que uno conoce el concepto del patrón y sabes lo que significa, pero nadie sabe
como lo implemeta el servidor de aplicaciones, lo que si sabes es que simpre vas a tener una única instancia de la clase.
Es más estoy seguro que GlassFishh lo hace de una manera y JBOSS lo hace de otra por ejemplo.
Por eso digo que el artículo tiene cosas que se rescantan dentro del contexto que lo explica (uno se puede equivocar y debe estar bien probado),
pero que el concepto se aplica en las librerias, estandares y framework más conocidos. Tal es asi, que uno puede buscar dentro de hibernate y
encontrar clases tal cual el patrón se encuentra documnetado. El tema esta en como el resto del hibernate administra de forma eficiento o no, esos singleston.
Como comentas muy bien vos, en Spring te abstraes de si es o no un Singleston, pero vos tenes idea si esos singleston o no de los cuales
te abstraes estan bien o mal administrado, seguramente me diras Spring es un producto muy probado y seguramente muy testeado que
hace que todo funciones bien. A lo que apunto es que te abstraigas no sinifican que no estan.
Por eso decia que estaba de acuerdo con Pablo que uno lo debe conocer y conocer otras alternativas, para saber cuando implementarlo de forma correcta
para que te aporte algo a tú desarrollo.
Y vuelvo con lo mismo a no te llama la atención que si bien es un patrón que se recomienda tener cuidado con su uso, muchos de los productos más conocido
lo implemnetan de una forma u otra, evidentemtente no todo es malo con el patrón.
Por ejemplo a mi me llama la atención que la especificacion de EJB 3.1 donde participan empresas muy reconocidas, decidieran agregar la anotación @Singleston
(lo que no significa que sea lo mejor muchas de esas empresas armaron la especificacion de EJB 2.1 y la verdad que no les fue muy bien). A lo que voy es que el
patrón tarde o temprano lo terminana usando por lo menos conceptualmente independientemente de como se implementa.
Si bien nos fuimos de tema con respecto al tema original, no estoy diciendo que static sea malo ojo, solo creo que se debe evaluar la mejor opción.
saludos.
Leo.
Subject: Re: [JavaSOS] Cual es mejor utilizar patron singleton o static?
Juan Carlos Martín
Feb 17, 2012, 10:56:51 AM2/17/12
to jav...@googlegroups.com
El 30/01/12 15:44, Leandro Spadaro escribió:
Este hilo me ha llevado a echarle un ojo a un libro que suelo
recomendar. Effective Java. Tiene una pequeña sección dedicada a
este asunto.
Saludos.
Saludos.
Gustavo Antonio Correa Caja
Feb 17, 2012, 11:06:51 AM2/17/12
to jav...@googlegroups.com
Alguien trabaja o a trabajado con struts 1 o 2 y sin Spring?
Porque ahora que todo es Spring; cuando trabajas con struts 2 por ejemplo tienes tus DAOs y luego para llamar a tus DAOs tienes que hacerlo por los Services luego en el Action de Struts hay tienes que llamar a tus services.
Ahora para que no llames 2 o n veces a tus Services tienes que aplicar el patron Singleton.
A mi parecer que hay se aplica bien el patron(osea cuando no utilizas Spring).
Espero me hallan entendido.
Saludos...
Porque ahora que todo es Spring; cuando trabajas con struts 2 por ejemplo tienes tus DAOs y luego para llamar a tus DAOs tienes que hacerlo por los Services luego en el Action de Struts hay tienes que llamar a tus services.
Ahora para que no llames 2 o n veces a tus Services tienes que aplicar el patron Singleton.
A mi parecer que hay se aplica bien el patron(osea cuando no utilizas Spring).
Espero me hallan entendido.
Saludos...
Reply all
Reply to author
Forward
0 new messages