Siento la tardanza en la respuesta. Yo haría una instancia de una clase en
un ámbito que se pudiera acceder desde donde necesitas los datos. En cada
caso supongo que es diferente. Un gestor de parámetros normalmente lo
metería dentro de un model. O incluso podría ser el model en si mismo y lo
metería como una propiedad de _level0. Pero sin duda seria una clase normal
y no una estática, estoy de acuerdo contigo.
Pero solo usaría un singleton si los servicios que provee fueran totalmente
ajenos a la aplicación.
Una cosa aparte que he leido sobre los singletons, y me parece interesante,
es que tienen una gran pega. Normalmente los clientes saben demasiado sobre
ella. Saben como se construye. Me refiero a lo siguiente:
<code>
class Documento implements Imprimible{
public function imprimir():Void{
Impresora.getImpresora().imprimir(this);
}
}
</code>
En este caso Documento *sabe* que Impresora es un Singleton, sabe como
conseguir instancias de esa clase. Sabe demasiado ;) Cuando podria ser:
<code>
class Documento implements Imprimible{
private var impresora:Impresora;
function Documento(i:Impresora){
if(i)impresora = i;
}
public function imprimir():Void{
impresora.imprimir(this);
}
}
</code>
De esta manera Documento no tiene ni idea de cómo se crea un impresora (ni
falta que le hace) que podria seguir siendo un singleton (o no) y la
aplicación puede tomar la decisión sobre como se consigue la instancia.
A mi me gusto mucho la solución cuando la vi.
Joseba Alonso
www.5dms.com
www.sidedev.net
> -----Mensaje original-----
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En
> nombre de Manuel de la Higuera
> Enviado el: lunes, 15 de noviembre de 2004 20:45
> Para: [EMAIL PROTECTED]
> Asunto: RE: [ASNativos] Singletons (era Recuperar una
> variablepasadaconloadMovieNum)
>
> Xavi sugirió en un principio el uso de una clase con un Singleton o en su
> defecto una clase estática. En mi primer reply objeté el error en la
> implementación y aclaré mi postura en cuanto a las clases que hacen de
> "data
> pools" (en principio, ese era el caso específico).
>
> Yo prefiero la utilización de un Singleton porque nunca se sabe qué código
> va a acceder a esa clase y prefiero centralizarla de esa forma, amén de
> los
> posibles cambios que puedan sucederse en esa clase (por lo que la prefiero
> antes que una estática), ej: internacionalización de un menú. De todas
> formas, si tengo claro que sólo será para almacenar datos, una clase
> estática con miembros estáticos es *exactamente igual* que tener un objeto
> en _global.
>
>
> Y una vez hecho tu análisis, ¿qué propondrías tú Joseba?
>
> M.
>
>
> > -----Mensaje original-----
> > De: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] En nombre de Joseba Alonso
> > Enviado el: lunes, 15 de noviembre de 2004 19:53
> > Para: [EMAIL PROTECTED]
> > Asunto: RE: [ASNativos] Singletons (era Recuperar una
> > variable pasadaconloadMovieNum)
> >
> > No era mi intención ser categórico, ni mucho menos. Creo
> > incluso que me has entendido mal. No estoy diciendo que el
> > singleton no tenga beneficios, ni mucho menos, solo estoy
> > diciendo que usar un patron singleton solo para obtener un
> > acceso global a una serie de funciones y variables no me
> > parece correcto. Ya que entonces tiene los mismos
> > inconvenientes y peligros que usar variables globales.
> > Pienso, y reitero, puedo estar equivocado, que la mision del
> > singleton es la de asegurar que solo haya una instancia de
> > una clase y proveer acceso unico a esa instancia, porque el
> > tener mas instancias de esa clase provocaría un
> > malfuncionamiento del programa. Y no veo que este sea el
> > caso, sino que simplemente se esta usando el singleton como
> > un sustituto a las variables globales, no porque el
> > funcionamiento de la clase en si lo exija. Asi que en teoría
> > este método sufriría de los mismos problemas que las
> > variables globales (excesiva dependencia..etc)
> >
> > Otra cosa que veo erronea es que el singleton que se ha
> > planteado crea un tipo Array, algo que no debería hacer ya
> > que si su misión es la de proporcionar el acceso a la
> > instancia, no le hace ningún bien el conocer como debe
> > crearse esa instancia en concreto, produce al "coupling" ¿no?
> > Bueno, esto es otro asunto, creo...
> >
> > Una cosa más en la que creo que me has malinterpretado es en
> > lo de las clases estáticas, tema que ya salio en otra
> > ocasión, y en el que estoy completamente de acuerdo contigo.
>
> >
> > Joseba Alonso
> > www.5dms.com
> > www.sidedev.net
> >
> > > -----Mensaje original-----
> > > De: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] En
> > > nombre de Manuel de la Higuera Enviado el: lunes, 15 de
> > noviembre de
> > > 2004 15:36
> > > Para: [EMAIL PROTECTED]
> > > Asunto: RE: [ASNativos] Singletons (era Recuperar una
> > variable pasada
> > > conloadMovieNum)
> > >
> > >
> > > Bueno, creo que es precipitado el ser tan categórico como
> > tú lo estás
> > > siendo. De hecho, creo que te confundes de pleno en el uso
> > del Singleton.
> > >
> > > Reservar el _global sólo a namespaces es una práctica
> > interesante de
> > > la que no todo el mundo pueda ser partícipe (tú, por
> > ejemplo). Xavi y
> > > yo coincidimos en que es mejor reservar _global para las clases. Es
> > > sólo una opción personal pero bastante más acertada y lógica que la
> > > tuya.
> > >
> > > Lo que has escrito no es, ni de lejos, exáctamente lo mismo que un
> > > Singleton. Son muchos los beneficios de usar un Singleton y no
> > > exclusivamente "proveer de un acceso global", que para eso
> > están las
> > > clases estáticas. Hay beneficios extra en el uso de
> > Singletons y uno
> > > de ellos (y muy importante) es el de poder luego mutarlo a Multiton.
> > >
> > > El utilizar Singletons es como evitar el "casa con dos
> > puertas difícil
> > > es de guardar" del refranero castellano. Publiqué en mi blog (en
> > > inglés) las diferencias entre clases estáticas y singletons, que
> > > reproduzco íntegro
> > > aquí:
> > >
> > > ---
> > > First of all, Static Classes are meant to be used as
> > Utility Classes.
> > > That is, they are a namespace that encapsulate a bunch of
> > functions.
> > > That doesn't help the OOP's paradigm point of view but they work
> > > pretty well as Façades or non-dynamic data classes; a static method
> > > will always need static members to interoperate --apart from
> > > arguments, that can be passed-- thus it may lack in further
> > > reusability.
> > >
> > > On the other hand, Static Classes are faster than Singleton
> > classes.
> > > They have no instance, so no object is created --just the global
> > > static object- -.
> > > Nevertheless, Singleton may (and should) use lazy instantiation,
> > > defering the instantiation until getInstance() is called, giving us
> > > total control over the instance creation.
> > >
> > > A Singleton class can be refactored as easy as 1-2-3 into a
> > "plain" class.
> > > It can also be refactored to have more than one instance (Multiton).
> > > Further
> > > more, static methods cannot be overriden whilst Singleton
> > classes can.
> > > UPDATE: Notice that shadowing can be made in static
> > classes. Shadowing
> > > is a bad practice by the way.
> > >
> > > Summing up, there's a tradeoff between flexibility,
> > extensibility and
> > > reuse
> > > (Singleton) versus ease of use and speed (Static classes).
> > I'm always
> > > choosing the former if I'm not really sure of the final
> > fate the class
> > > will have, so I can be ready for future issues.
> > >
> > > A real-world example may be a Luggage class. Initially, we can just
> > > code some static methods --to check in, to transport-- as
> > Luggage is
> > > not responsible for that purposes. However, specifications
> > may change
> > > and later we could need enumerations and non-static methods (for
> > > example, to add garments). A Singleton class will suit this topic
> > > seamlessly.
> > >
> > > We could be asked, too, to balance between two different
> > Luggages (so
> > > check in doesn't cost too much and you can have hand
> > luggage without
> > > paying for
> > > overweight) and Singleton will go Multiton.
> > > ---
> > >
> > >
> > > HTH,
> > >
> > > M.
> > >
> > > ----------------------------------
> > > Lista ASNativos:[EMAIL PROTECTED]
> > > http://www.5dms.com/listas
> > > ----------------------------------
> >
> > ----------------------------------
> > Lista ASNativos:[EMAIL PROTECTED]
> > http://www.5dms.com/listas
> > ----------------------------------
> >
>
> ----------------------------------
> Lista ASNativos:[EMAIL PROTECTED]
> http://www.5dms.com/listas
> ----------------------------------
----------------------------------
Lista ASNativos:[EMAIL PROTECTED]
http://www.5dms.com/listas
----------------------------------
