Todavía no leí el articulo, pero está mal decir que algo es malo porque trajo muchos problemas, primero hay que ver si esos problemas no vinieron por usar mal los singletons, por no haber entendido el concepto (como el error que cometí yo mismo al decir que los singletons no tienen estados).
Dejemos de lado los errores "groseros" (no se si aplica 100% esta palabra) que se cometen al querer que el singleton haga cosas extrañas. Porque si vemos que nuestro singleton no es tan singular y debería comportarse distinto según quien lo llame y solo intentamos usar el singleton para no tener tantas instancias en memoria de algo que se comporta similar en muchos casos, entonces necesitamos un patrón flyweight. Creo que los 2 tips fundamentales para implementar un buen y simple singleton son 1- No hacer jerarquías de singletons. 2- Tener bien en cuenta los problemas de concurrencia múltiple. En programas pequeños, puede andar bien un simple synchronized en los métodos críticos, pero en sistemas grandes, hay que estudiar bien si el framework que estamos utilizando no hace ese trabajo "sucio" por nosotros. Por otro lado, una vez escuché por ahí "Todo singleton es culpable de ser una variable global (malo) hasta que demuestre lo contrario" Es decir, existen casos en que los singleton son necesarios para tener un buen diseño, pero solamente hay que saber dónde ponerlos. El día 28/09/07, personaje <[EMAIL PROTECTED]> escribió: > > From: Leandro Lucarella <[EMAIL PROTECTED]> > Date: Sep 27, 2007 5:27 PM > Subject: Re: [Prog] singleton con parametros > To: Una lista para consultas de programación < > [email protected]> > > > > No quiero hacer un rant de esto, sólo les dejo un artículo con algunas > > desventajas de los singleton, cada uno que saque sus conclusiones y > > que evalúe si conviene en cada caso: > > http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx > > Yo tampoco quiero flame ni nada por el estilo; leí el link y me parece > interesante. Plantea los problemas de los singletons, pero no da (o no > identifico) una solución viable. > > Siempre que planteo mi problema pienso en un objeto preferencias > > Viene la parte sólo para los que RTFA: > > 1 dice que un sigleton es como una variable global, y que eso es malo. > Ahora, qué solución propone? pasar parámetros (referencia) a todas las > clases que haga uso de la misma. > Claro, con eso solucionás el problema, la creas una vez en el main o > initialize o donde sea, y la pasas para todos lados. Pero eso me > resulta /peor/ que un objeto global... cómo mantengo eso? si tengo que > refactorizar me muero > cómo podría evitar andar pasando referencias por todos lados? > 2 me dice que no le delegue más de una responsabilidad a la clase > (estamos de acuerdo), pero si la capacidad de ser singleton la > "hereda"?, no están separadas las responsabilidades? También > recomienda delegar la unicidad de la clase a un factory... yo a los > factories los uso como singletons... ahhh!! chicken and egg!!! =P > 3 de acuerdo... cómo lo soluciono? si tengo las referencias que pasan > por todos lados no es similar? > 4 está bien, lo admino, no hago unit testing... pero si recibo una > referencia con un estado que puede haber modificado otra clase (que > puede no estar en el unit), no tengo el mismo problema que plantea? > > Sin ganas de flame, sólo de aprender, > Perso > > _______________________________________________ > Lista de correo Programacion. > [email protected] > http://listas.fi.uba.ar/mailman/listinfo/programacion > -- Abel Sebastián Fillol
_______________________________________________ Lista de correo Programacion. [email protected] http://listas.fi.uba.ar/mailman/listinfo/programacion
