Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





No Me Gustan Los Singletones

Iniciado por DraKKaR, 03 de Octubre de 2004, 12:27:43 PM

« anterior - próximo »

sés

 Creo que lo mejor es lo que dijo Mars, si no te gusta... pues no lo uses y punto. Es lo que hago con todos los "patrones".

Hace un tiempo me dieron un curso sobre patrones y mi conclusión es:
Alguien se aburría, puso nombres a cosas que todos hacemos constantemente cuando programamos y nos los venden como la repanocha.

Claro, que en informática siempre es así. A la gente le gusta poner nombres chulos a auténticas chorradas para poder vacilar en las reuniones... (nooo)
Soy indeciso... ¿o no?

martiño

 - Desde un punto de vista conceptual un singleton no es mas que una variable global mejorada (eso no lo digo yo que lo dice en el "Design Patterns") y las variables globales nunca fueron buenas, se debe usar cuando no se pueden hacer las cosas de otra forma.

- Por otra parte decir que la implementacion de ethernet del singleton es la mas habitual. Todo son ventajas, no hay que usar un "if", se llama al destructor del singleton siempre al cerrarse el programa y no es cierto que se instancie siempre el objeto aunque no lo necesites, ya que las variables estaticas dentro de una funcion se inicializan la primera vez que la función se llama, no al empezar el programa. Ademas, y si no me falla la memoria, esa forma la inventó Meyers, que no es poco.

Grugnorr

 Los Singleton en C++ son _necesarios_ , el órden de creación de variables globales entre distintas compilation units( librerías, exe... ) no es ni predecible ni portable. En cuanto tengas que una depende de la otra....

Los Singleton en C#, Java y demás lenguajes puros es la única forma de tener una "variable global", ya que no existen las variables fuera de clases

Yo resumiría que en cuanto el sistema es minimamente complejo...

PD: Aunque los Patterns fueran sólo "nombres molones a cosas hechas por siempre", ya serían útiles para poder explicarle a otra persona qué leches quieres decir con eso de un Listener, etc

PD2: El libro Design Patterns debe ser el que más me ha enseñado de programación de los muchísimos que he leido. Sés, lo has leido? :blink:  
hat the hells!

sés

 
Cita de: "Grugnorr"Aunque los Patterns fueran sólo "nombres molones a cosas hechas por siempre", ya serían útiles para poder explicarle a otra persona qué leches quieres decir con eso de un Listener, etc
Estoy de acuerdo. Pero creo que no me has entendido del todo. Hay "Desing Patterns" que sí, que vale, que son útiles... incluso algo "nuevo", pero la mayoría son solo nombres que han puesto a cosas que casi todos hacemos sin que nadie nos las explique.

Es como si yo ahora le pongo un nombre al código con el que recorro un array, lo hago con varias cosas más y al conjunto le pongo un nombre "molón" como... digamos... ¿"Design Patterns"? :P

Ojo: Yo NO digo que estén mal, al contrario, pero se venden como si fuera el invento del siglo o algo nuevo y simplemente son cosas viejas que alguien juntó y las puso nombres.


Cita de: "Grugnorr"El libro Design Patterns debe ser el que más me ha enseñado de programación de los muchísimos que he leido. Sés, lo has leido? :blink:
No, no lo he leído, pero me han dado un curso en el que me explicaron bastantes patrones y mi conclusión fue esta. Salí igual que entré, no me enseñaron nada que no supiera ya... aparte de los nombres que, por cierto, he olvidado casi todos.

Personalmente no me interesa cómo ha decidido alguien llamar a algo que llevo escribiendo años.

"Mira, que ilu, ahora puedo llamar a este cacho de código Message Facade..." Muy útil, sí señor :lol:
Soy indeciso... ¿o no?

ethernet

Cita de: "Grugnorr"Los Singleton en C++ son _necesarios_ , el órden de creación de variables globales entre distintas compilation units( librerías, exe... ) no es ni predecible ni portable. En cuanto tengas que una depende de la otra....

precisamente esa es una gran ventaja en algunos sistemas, con el singleton puedes perfectamente saber en qué orden se contruyen y se destruyen las instancias de las clases singletonizadas, lo cual es muy adecuado para diferentes subsitemas que dependen a su vez de otros

saludos

Grugnorr

 Eso es precisamente lo que intentaba explicar  :P .
hat the hells!

martiño

 
CitarEstoy de acuerdo. Pero creo que no me has entendido del todo. Hay "Desing Patterns" que sí, que vale, que son útiles... incluso algo "nuevo", pero la mayoría son solo nombres que han puesto a cosas que casi todos hacemos sin que nadie nos las explique.

Que levante la mano el que habia hecho por su cuenta un "singleton" antes de oir hablar de el, o un "state" o un "visitor".

sés

 
Cita de: "martiño"Que levante la mano el que habia hecho por su cuenta un "singleton" antes de oir hablar de el, o un "state" o un "visitor".
*levanta la mano*

Yo he hecho cosas muy parecidas a eso. Y vamos... los singletons los uso desde antes de saber C++; la típica función que te devuelve un objeto (estructura o variable) que solo es inicializado o creado una vez... como que no es nuevo.
Soy indeciso... ¿o no?

tamat

 Pues Ses, será que eres un iluminado, porque yo antes de leer el design patterns me dedicaba a lanzar punteros por todo el código hasta que leí el patron Singleton.

Y como han dicho por ahí arriba es una buena manera de etiquetar diferentes maneras de organizar el código, siempre va bien para comunicarte con otros programadores.
Por un stratos menos tenso

sés

 No, no soy ningún iluminado :P

Nunca he dicho que los patrones estén bien o mal. Lo que si digo es que nos los venden como la repanocha de la programación y el diseño.

Cuando en el trabajo me enviaron a un curso en el que nos iban a enseñar patrones, al terminar mi sensación fue de "coño, me han timado" (bueno, más bien a la empresa ^_^).

A ver, algunos patrones están bien, algunos muy bien y otros... en fin, están. Pero todo eso no es más que estructuras y métodos para hacer ciertas cosas que, si nadie te las enseña, acabarás descubriendo tú solito. La única diferencia es que tú no les pondrás esos nombres tan "guays". En fin, que se le va a hacer, estamos en la época de los nombres chulos y las siglas.

Yo llevo bastantes años dando al teclado y ese curso me sirvió más bien de poco. Lo único que saqué fue un montón de nombres para llamar a las cosas que yo ya hacía.


P.D.: Ah, sí... ya olvidé casi todos los nombres.
Soy indeciso... ¿o no?

CoLSoN2

Cita de: "sés"Lo único que saqué fue un montón de nombres para llamar a las cosas que yo ya hacía.
A parte de que para mí sí son útiles para aprender nuevas formas de solucionar ciertos problemas de POO, no crees que ya por el hecho de tener un nombre que "todos los programadores conocen" (o deberían) ya es un logro? Así si hablas con alguien en el curro, sea en el que llevas 5 años o en uno al que acabas de llegar, puedes explicar perfectamente como pretendes diseñar una determinada arquitectura sólo utilizando esos nombres, y todos te entenderán.
Manuel F. Lara
Descargar juegos indie  - blog sobre juegos indie y casual
El Desarrollo Personal.com  - blog sobre productividad, motivación y espíritu emprendedor

sés

 Ya lo he dicho varias veces. Ni me gustan ni me disgustan.

De lo único que me quejo es que nos venden nombres de cosas (que cualquiera que lleve cierto tiempo programando conoce la mayor parte de ellas) como algo mágico.


Es como enseñar a un novato un bucle como este:
for( int i=0; i<a.length; i++ ) System.out.println( a[i] );

Y decirle:
- Esto es el patrón "Array recorrer".

¿Está bien que sepa cómo llamarlo para que otros le entiendan? Pues sí. Pero no deja de ser un trozo de código genérico para recorrer un array.

No es nada mágico, y lo venden como si lo fuera.

Como en todo, a algunos les parecerá la releche y a otros una castaña. A mí simplemente me parece que es algo útil, pero no más que un "Code of the Day", y que se le da demasiada importancia... a algunos les hablas de "Design Patterns" y tienen un orgasmo XD
Soy indeciso... ¿o no?

Pogacha

 Todavia no entiendo por que  (supongo las complicaciones que tendria el compilador) no existe la maldita instancia unica de clase:

class {
 // por ejemplo manipulador de memoria o para lo que se use un singleton;
private:
this();
 ~this();
} InstanciaUnica;

Donde el linker la instancie y destruya.

Así serviria de namespace con miembros privados y heredables para su uso:

En la herencia no se crearía una instancia sino que solo daria accesos a todos los miembros de la instancia unica pues estos son estaticos y unicos.

class TUsador_1_De_LaInstanciaUnica : public InstanciaUnica
{
  // Por ejemplo render opengl
} ;

class TUsador_2_De_LaInstanciaUnica : public InstanciaUnica
{
  // Por ejemplo render directx
} ;

Igual esto no contribulle a nada, es solo un loco pensamiento, seguramente hay muchas razones por las cual esto no se pudo implementar en el c++.

Saludos
PD: no me hagan caso  (asco) .

fiero

 Estaba leyendo por ahí y al toparme con este post http://www.flipcode.com/cgi-bin/fcmsg.cgi?...read_show=24426 me ha hecho gracia y me he acordado de lo que dice sés. Estoy totalmente deacuerdo con sés, la gente se aburre y pone nombres a cosas, eso es bueno, para reconocer ciertos hábitos de programación, pero tampoco hay que tomarselo como la revolución de la programación ni pensar que si no se dominan todos esos nombres no se puede programar bien XD. En el post del link se habla del "Patrón de diseño del pollo y el huevo", vamos, pa cagarse XDD

un saludo
www.videopanoramas.com Videopanoramas 3D player

Javi SJ Cervera

 Yo he visto como NeoEngine usa singletones, y creo que está bastante bien.

La principal clase del engine es la clase "Core". No necesitas instanciar nada, sólo hacer Core::Get()->metodo(). La primera vez que llamas a Core::Get(), se creará una instancia "Core" y se devolvera el handle, el resto de las veces sólo devuelve el handle al objeto, para asegurarse de que sólo exista uno en la aplicación.
== Jedive ==






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.