De acuerdo, cada maestrillo tiene su librillo. A mí personalmente el utilizar _level0 me parece una mala práctica y simplemente vela el uso de una clase estática o de un singleton. Ya sabes que yo soy muy estricto (hay gente que me llama dogmático) en el uso de la terminología y *me niego* a que se acepte la jerarquía de los MovieClips como un composite. Una vez se pierde el carácter mitótico (i.e.: crear un hijo a partir exclusivamente del padre) se pierde también el "Composite".
Un MovieClip, para crear un hijo a su imagen y semejanza, necesita de un ID de la librería --sí, vale que existe el hack del __Package, pero no es built-in ni documentado-- o bien un duplicateMovieClip, que genera un MovieClip idéntico sí, pero nunca podrá formar parte de los hijos de él mismo. Asímismo, no puede haber movieclips independientes de _root. Ya conocía el link que has puesto --si no conociera los inconvenientes de las cosas de las que hablo, sería muy poco ético por mi parte hablar de los pros--. Btw, gracias por compartirlo con la lista, merece la pena echarle un vistazo. M. >-----Mensaje original----- >De: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] En nombre de Joseba Alonso >Enviado el: miércoles, 17 de noviembre de 2004 16:34 >Para: [EMAIL PROTECTED] >Asunto: RE: [ASNativos] Singletons >(eraRecuperarunavariablepasadaconloadMovieNum) > > >> _level0 viene a ser casi igual a nivel práctico que _global. >No existe >> casi diferencia entonces entre usar una clase estática o una clase >> "normal", salvo en el uso de instancias. > >El uso de instancias es una razón suficiente ¿no? Vamos, las >mismas que tiene el singleton sobre las clases estáticas. > >Yo muchas veces utilizo _level0 directamente como view cuando >la aplicación es sencilla. Entonces instancio un pequeño model >directamente ahí. A eso me refería. Al fin y al cabo toda la >jerarquía de MCs que utiliza Flash es un composite. Luego >podrías cambiar esa instancia por un subtipo sin preocuparte. >Como la ampliación a internacionalización que comentabas. > >> >> >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. >> >> Eso sólo ocurre cuando la implementación no es lo suficientemente >> flexible. >> Lógicamente es mucho mejor que la construcción de la instancia sea >> invisible para sus suscriptores, pero eso depende del diseño de la >> aplicación y no del Singleton en sí mismo. De hecho, en muchas >> ocasiones se recurre a una clase que hace de Proxy para >devolver la(s) >> instancia(s) de un singleton/multiton, ya que aumenta la >flexibilidad >> de las clases que utilizan esas instancias. >> El no hacer estos cambios en la flexibilidad podría desembocar en la >> violación del principio de sustitución de Liskov[1]. >> >> >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. >> >> Estoy de acuerdo con ello, pero el caso que nos ocupa es una clase >> totalmente dependiente de otra y no una agregación. No veo >qué sentido >> tiene evitar el getInstance() si es una clase final. >> >> Por favor, ilumíname. >> > >No, era un tema aparte ("> >Una cosa aparte que he leido sobre >los singletons" ). Lo habia leido y me había parecido bastante >interesante comentarlo en este contexto. > >Igual ya lo habías leído, este documento me ha parecido >interesante sobre el >tema: >http://www-106.ibm.com/developerworks/webservices/library/co-si >ngle.html > >Un saludo, > >Joseba > >---------------------------------- >Lista ASNativos:[EMAIL PROTECTED] >http://www.5dms.com/listas >---------------------------------- > ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ----------------------------------
